AIコーディングツールを業務で使うようになって、しばらく試行錯誤した結果、自分の中で一つの比喩に落ち着きました。
AIは地頭が良く自信過剰な新人。学習で成長するが、経験や判断・責任は持てない。
人間と同じで、情報量が多かったり長かったりすると手順が抜ける。
この一文に、AI活用で気をつけるべきことの大半が詰まっていると思っています。
なお、最近は「バイブコーディング(vibe coding)」── コードを読まずに雰囲気で動かすスタイル── も話題になっていますが、ここではコードを理解した上でAIを使う前提で話を進めます。理由は最後に触れます。
少し分解してみます。
地頭が良く自信過剰
基礎能力は高いと感じます。言語の構文、よくあるパターン、定型的な実装は、並のエンジニアより速くて正確に書けることが多いです。
問題は自信過剰なところかなと思います。新人なら「分かりません」と言える教育ができますが、AIは知らないことも自信を持って答えがちです。推測を事実のように提示することもあります。レビューで指摘されるまで、自分の間違いに気付かない。
なので「AIができたと言っている」を鵜呑みにしないほうが安全だと思います。テストが通ったと言われても、テスト自体が間違っていることもあります。動きましたと言われても、エッジケースで壊れていることもあります。AIの自己評価は当てにしない、というのが付き合い方の出発点になりそうです。
学習で成長するが、経験は持てない
モデルのバージョンが上がれば賢くなります。これは新人が研修を受けて成長するのに似ています。
ただし、新人と決定的に違うのは、経験が蓄積されないことかなと思います。先週教えたことを今週には忘れている。昨日の失敗から学べない。会話を超えて成長することができない。
新人なら3ヶ月もすれば「あの先輩はこういうレビューをする」「このコードはこう書くと怒られる」を体で覚えると思います。AIにはそれがない。なので、経験で覚えるはずだったことを、すべて外部に明文化して毎回読ませる必要が出てきます。
これがCLAUDE.mdやskillsといった「ハーネス」を書く労力の根本的な理由かなと思っています。手間に見えますが、新人を毎朝オンボーディングし直していると思うと、納得感があります。
判断や責任は持てない
ここが重要なところだと思います。
個別の実装判断はAIで代替できそうです。しかし「何を作るか」「どう設計するか」「何を捨てるか」というメタな判断は、人間がするしかないかなと思います。
そして、障害が起きたとき、規制対応が必要になったとき、責任を取るのは人間です。「AIが書いたので分かりません」では通用しません。なので、最終責任を取れる人間がコードを理解している状態を保つ必要がありそうです。
これを忘れて全部任せると、後で困りそうだなと思っています。
情報量が多いと手順が抜ける
長い会話、複雑なタスク、たくさんの指示── 文脈が膨らむと、序盤に伝えたルールへの注意が薄れます。人間も認知負荷が高くなるとミスが増えますが、AIでも似たことが起きます。
「絶対に」「必ず」と書いても、確率を上げるだけで、ゼロにはならない。指示は破られうる前提で設計するのが現実的かなと思います。
どう付き合うか
この比喩から、付き合い方の指針が自然に導けそうです。
任せる領域と、人間が手を動かす領域を分ける
定型的な実装、ドキュメント生成、既存パターンの踏襲はAIに任せやすいと思います。一方で、設計判断、難しいバグの調査、ドメインモデリング、セキュリティに関わる実装は、人間が手を動かす価値があります。前者で時間を浮かせて、後者に投資するのが健全かなと思っています。
経験の代わりに、ハーネスで明文化する
プロジェクトのコーディング規約、ドメイン用語、よくある落とし穴、タスク完了の定義── これらは「経験で覚えるはずだったこと」です。CLAUDE.mdやskillsに書き出して、毎回読ませる。AIに書かせて、人間がレビューしてもいいと思います。
私が実際にやっているのは、指摘が終わった後に「学習できることはありましたか?」と聞く運用です。AIが自分で気付きを言語化して、関連するファイルに追記してくれます。
最初は「メモリだけじゃなくて、プロジェクトのskillsにも入れて」と指示していましたが、一度CLAUDE.mdに「学習はメモリだけでなく関連skillにも追記する」と入れたら、以降は指示しなくても自動でやってくれるようになりました(たまに忘れますが、新人と同じですね)。
経験は持てないけれど、経験を毎回外に出して蓄積する仕組みは作れる、という感覚です。
加えて、書いたコードを別のモデルにレビューさせることもしています。同じモデルだと自分の間違いに気付きにくいですが、違うモデルなら指摘が入ります。実際、一つのモデルでは解決できなかった問題が、別のモデルだとあっさり解けたこともありました。自信過剰な新人に、別の視点からのレビューを入れる感覚に近いです。
重要なものは指示ではなく仕組みで担保する
「rm -rfしないで」とCLAUDE.mdに書いても、確率的に外れます。本当に止めたいなら、hooksやツール権限で物理的に実行できなくする。指示は新人への口頭注意、仕組みは鍵付きの引き出し、と考えると分かりやすいかなと思います。
自己評価を信用せず、検証する
AIの「できました」は信用しない。動作確認、テスト、レビューは別途やる。これは「AIを疑う」というより、「自信過剰な新人にはレビューが必須」という当たり前の話だと思います。
最終責任は人間が持つ
判断と責任は人間の領域に残す。重要な操作には承認ゲートを置く。コードベースの「理解者」を意識的に育てる。AIで効率は上がりますが、責任構造は変わらないかなと思います。
バイブコーディングについて
冒頭で触れた「バイブコーディング」に戻ります。コードを読まずに、AIが出したものをそのまま使うスタイルです。
個人のプロトタイプや、捨てる前提のコードならアリかもしれません。試行錯誤の速度は確かに上がります。
ただ、商用サービスや継続的に運用するコードでこれを続けると、いくつか問題が出てきそうです。
自信過剰なAIを検証なしで信頼することになる。前述の通り、AIは知らないことも自信を持って答えます。読まずに使うと、間違いに気付けません。
コードベースの理解者がいなくなる。動いているうちはいいのですが、障害が起きたとき、リファクタが必要になったとき、移行のとき── 「誰も中身を知らない」状態は致命的です。
責任を取れる人がいなくなる。「AIが書きました、読んでません」では、ユーザーにも規制当局にも通用しません。
長期的にスキルが空洞化する。読まないと、設計判断の経験も、デバッグの経験も蓄積されません。3年後、5年後に困りそうです。
なので、AIを使うこと自体は良いとして、コードを読まずに使うのは避けたほうがいいかなと思っています。AIに書かせても、人間が読んで理解する。理解できないコードは、AIに説明させてから使う。この一手間が、長期的にはかなり効いてきそうです。
長期的な視点
短期的にはAIで圧倒的に速くなります。これは事実だと思います。
ただし、何も考えずに任せ続けると、シニアが育たない、ジュニアが育つ機会を失う、誰もコードベース全体を理解していないという状態になりかねないと感じています。これは数年単位で進行する問題で、気付いたときには深い負債になっていそうです。
効率と、人間の能力維持のバランスを、意識的に取りに行く必要があるかなと思います。「AIを使わない」のではなく、「意図的に人間が手を動かす領域を残す」「AIが書いたコードも、人間が読んで理解する」発想です。
まとめ
AIは地頭が良く自信過剰な新人。学習で成長するが、経験や判断・責任は持てない。情報量が多いと手順が抜ける。
この比喩を持っていると、過剰な期待にも過剰な不信にも振れずに済むかなと思っています。新人マネジメントの常識がほぼそのまま使えますし、足りない部分(経験できない、責任を取れない)を仕組みで補えばいい。
振り返ってみると、ここで書いたことは特に新しい話ではないなと思います。新人にはオンボーディング資料を渡す。重要な手順はチェックリストにする。レビューは別の人にも見てもらう。危険な操作には承認を入れる。理解できないコードはマージしない── 普段のエンジニアリングでやっていることばかりです。
AIだから特別な何かが必要、という話ではなく、これまでの開発の作法を、相手がAIになっても同じように続ける。それだけのことかなと思っています。
新しい道具は出てきましたが、良いソフトウェアを作るためにやることは、たぶん大きくは変わらないんじゃないかなと。
