先日の友の会でのことです。
友の会というのは、Claude Codeの使い方や困りごとを持ち寄る勉強会です。
この日、ある参加者の方からこんな相談がありました。
この方は、AIでブログを書くのはまだこれからで、今は会社の中で使う業務のシステムを、一つずつ順番に作っておられます。
使っているAIは2つ。
Claude Codeと、ChatGPTのCodexです。
作ったシステムを、この2つに互いにチェックさせているそうです。
見てもらうのは、セキュリティに穴がないかと、性能に問題がないか。
ただ、AIに任せても、どうも要領を得ない。
だから今は、毎回ご自分で指示を出して、一つずつチェックしてもらっている。
そろそろ自動化したほうがいいのか、自動化したら何か危ないことはあるのか、というご相談でした。
CodexとClaude Codeの併用は、試している方も多いと思います。
1つのAIだけに見てもらうより、別のAIにも見てもらったほうが、なんとなく安心ですよね。
ところが、この見せ合い方には、ちょっとした落とし穴があります。
CodexとClaude Codeにレポートを見せ合うと、何が起きるか
まず、どうやってチェックさせているのかをお聞きしました。
やり方はこうです。
片方のAIに「このフォルダにシステムを作ったからチェックして」と頼んで、改善点をレポートにまとめてもらう。
そのレポートを、今度はもう一方のAIに見せる。
僕も一時期、同じようなことをよくやっていました。
なので、まずこう聞きました。
「結構トンチンカンな方向になりません？」
この方は、今のところレポートを読む限りは的確だとおっしゃいます。
それなら、と続けて聞きました。
「なんかあら探しみたいになりません？」
これには「それはそうかもしれない」というお返事でした。
「改善点をまとめて」と頼めば、AIは改善点を探しにいきます。
そのレポートを受け取った側のAIも、また直すところを探しにいきます。
お互いに直すところを探し合う形なので、あら探しに寄っていくのも無理はないんです。
この方が丁寧にやりたい理由も、お聞きしてよく分かりました。
個人情報はAIには入れないけれど、作っているシステムのほうには入れる。
しかもウェブで動かしているので、そこは慎重にやりたい、ということでした。
これは本当にそのとおりで、僕もこう返しました。
「AIの弱点はそこなんですよ。容易に情報流出させちゃう部分の、そこがすごく甘いんですよ」
お客様の情報が外に漏れてしまう穴は、AIが書いたコードの中でも、いちばん甘くなりやすいところです。
そこに個人情報が入るとなれば、慎重になるのも当然ですよね。
「認証を増やせ」と言われたとき、どう受け止めるか
では、セキュリティの穴を探してもらうと、どうなるのか。
この方によると、AIはけっこう無理なことを言ってくるそうです。
たとえば、認証を増やせ。
言われたとおりにしようにも、できないことを平気で言ってくるわけです。
それでも僕は、その指摘を聞き流さなくていいと思っています。
「一応意見として聞いて、こういう条件だとどうしたらいいっていう風に掘り下げていくのはありですよ」
認証を増やせないなら、この条件でどう守ればいいか。
こちらの事情を伝えたうえで、もう一度聞き直すんです。
そうやって掘り下げていけば、無理な指摘も、こちらの事情に合った守り方を考えるきっかけになります。
ただ、聞き直すたびに、レポートを読んで、条件を考えて、また頼むことになります。
一つずつ指示を出しているこの方の手間は、ここでさらに増えていきます。
Claude Codeにコードのレビューを頼む前に、書かせるもの
そこで僕がお伝えしたのが、頼み方そのものを変えることでした。
「やるなら仕様書書いてくれとかの方が。リバースエンジニアリングして仕様書書く」
リバースエンジニアリングというのは、できあがったものから逆にたどって、どういう作りになっているかを書き起こすことです。
ここでは、できあがったコードをAIに読ませて、このシステムが何をするものなのか、どういう決まりで動いているのかを、仕様書の形で書いてもらいます。
そうやってできた仕様書から、もう一度見直すんです。
目の前のコードを一行ずつ追いかけるより、そのほうが穴を見つけやすいと思います。
仕様書になっていれば、どんな情報がどこに入って、どこへ渡っていくのかが、文章で並びます。
そこで初めて、ここで外に漏れてしまわないか、という見方ができるようになるんです。
コードだけを渡されたAIは、目の前に書いてある一行一行の良し悪しを見るのが精いっぱいです。
この方も、ここで「あ、そっか」と気づかれたようでした。
「コード全部渡してチェックしろじゃなくて、リバースエンジニアリングしてみろはいいかもしれないですね」
コードを全部渡して、チェックして、と頼む。
これは、この方が今やっている頼み方そのものです。
同じAIに同じコードを渡しても、頼み方を変えるだけで、見えてくる穴が変わってくるんですよね。
もっと楽にならないか、という声に僕が返したこと
この話のあとに、僕はこうもお伝えしました。
大雑把にやるより、細かくやったほうがいい。
それでうまくいくようなら、チェックの手順書を作って、それに沿ってやってね、と頼めばいい。
「最初は細々やった方がいいです」
自動化したいというご相談に、もっと手間をかけてくださいと返したわけです。
この方の本音も、そこにありました。
今でもレポートを読んだりしていて、けっこう大変。
もっと楽にならないかなと思っていた、と。
毎回指示を出して、レポートを読んで、また指示を出す。
それを続けてきた末の答えがこれでは、がっかりしますよね。
それでも、僕の答えは変わりませんでした。
「いや、やるんだったら正しい工程ですよ」
まず仕様書で、このシステムが何をするものかを固める。
そのうえで、全体をいっぺんに見ずに、機能ごとに小さく分けて確かめる単体テストから進めていく。
その確かめ方がうまく回るようになったら、手順書に起こして、AIにそれに沿ってやってもらう。
自動化は、その手順書ができてからでも遅くありません。
Claude CodeとCodexを併用している方は、次にチェックを頼むとき、まずはコードから仕様書を書いてもらうところから試してみてください。
ai.msup.bizのAI導入サポートでは、Claude Codeを社内の仕事に組み込むところから、一緒に進めています。
AIにどこまで任せていいのか迷っている方は、お気軽にご相談ください。