AIの暴走を防ぐ4原則
午前3時。 薄暗い部屋の片隅で、私はすっかり冷め切ってゴムのような食感になったマックフライポテトを口に放り込み、ディスプレイを睨みつけていました。目はひどくしょぼつき、肩から首にかけては鉛のように固まっています。どこからともなくSlackの通知音の幻聴さえ聞こえるような、そんな時間帯です。
Cursorに向かって、ここのバリデーションをちょっと追加しておいて、と軽く頼んだのがすべての始まりでした。 数秒で画面いっぱいに広がる、見たこともないような見事な抽象化クラスの数々。 おお、すごいな、さすが最新のAIモデルだ。 そう感心したのも束の間、テストコマンドを走らせた瞬間、画面は無情にも真っ赤に染まりました。 関連する依存関係が根こそぎ破壊され、50個以上のエラーログが滝のようにターミナルを流れ落ちていく光景。
頼んでいないログイン処理の過剰なリファクタリング。 意味不明なほど再利用性を高められたせいで、かえって用途が分からなくなった単一用メソッド。 親切心のつもりなのか、勝手に書き換えられた長文の英語コメントたち。
ちくしょう、そこは触らなくていいって何度も言ったじゃないか……。 思わず誰もいない部屋で叫んでみましたが、当然ながら返事はありません。ただ、冷え切ったディスプレイが静かに青白い光を放っているだけです。 呼吸が少し浅くなり、胸の奥がキュッと締め付けられます。冷凍庫の奥深くで3週間放置されている有機野菜のように、私の気力も完全に底をつきかけていました。
最新のAIツール、特にLLMを使ってコーディングをしたことがあるエンジニアの方なら、きっと一度は似たような絶望を経験されたことがあるはずです。 最近のAIは、確かに圧倒的に賢くなりました。信じられないスピードでコードを生成します。しかし、時として彼らは、恐ろしく気は回るけれども致命的に空気が読めない新入社員のように振る舞うことがあります。 手綱を緩めて放っておくと、彼らは勝手にこちらの意図を推測し、無駄に複雑な抽象化を施し、頼んでもいないのに隣接するレガシーコードにまでメスを入れてしまいます。そして最終的には本来の目的を完全に見失い、プロジェクト全体を迷走させるのです。
本当に欲しいのは、ただ普通に動くシンプルなコードなんだけどな。 これまでに何度、パソコンの画面に向かってそうつぶやいたか分かりません。
もしあなたが私と同じような痛みを味わい、AIの親切すぎる暴走をコントロールすることに疲弊しているなら、この記事はきっとお役に立てるはずです。 本日は、元TeslaのAIディレクターであり、OpenAIの創設メンバーの一人でもあるAndrej Karpathy（アンドレイ・カルパシー）氏の知見に基づく、AIコーディングにおける4つの黄金原則をご紹介します。 彼はX（旧Twitter）で数百万人規模のフォロワーを持つAI開発者コミュニティの最重要人物の一人であり、2025年初頭に「Vibe Coding（バイブコーディング）」という概念を提唱したことでも知られています。そして2025年末からは自らのコーディング作業のほぼすべてをAIエージェントに委任し、人間の役割はオーケストレーター（指揮者）であると公言しています。 だからこそ、彼のAIとの接し方における人間側のスタンスの定義は、極めて実践的で厳しいのです。
これは、プロンプトをこねくり回すような小手先のテクニック集ではありません。 そもそも我々人間がAIという強大な力に対してどう振る舞うべきかという、非常に泥臭く、しかし本質的なガイドラインです。
少し前まで、私たちはAIのことを便利な壁打ち相手、あるいは優秀な検索エンジンの代わりくらいにしか思っていなかったはずです。 それが今やどうでしょうか。 CursorのComposer機能やClaude 3.5 SonnetのArtifactsなど、エディタやシステムに深く統合されたAIエージェントたちは、私たちが書いたコードベースの全体を瞬時に読み込み、勝手に解釈し、ものすごいスピードで数十のファイルを並行して書き換えていきます。 彼らがもたらす圧倒的な生産性に溺れ、私たちはいつしかAIを、頼めば何とかして形にしてくれる魔法の杖として甘やかしてしまったのではないでしょうか。プロンプトエンジニアリングの終焉とAIエージェントの夜明けでも触れましたが、AIとの付き合い方は今まさに大きな転換点を迎えています。
その結果が、あの深夜の真っ赤にインクをぶちまけたようなテストの失敗画面に繋がっています。 魔法など存在しません。このシステム上にあるのは、人間の不完全な指示を、不完全な文脈のまま解釈し、ものすごい馬力で突っ走る巨大な計算機だけです。 チャットインターフェースという親しみやすいデザインが、言葉足らずでもいい感じに文脈を汲み取ってくれるはずだという、我々人間側の見事な認知バイアスを引き出しているに過ぎません。
だからこそ、私たちは今一度、AIとどう協働すべきかという型を取り戻さなければならないのです。
コーディングの前に、自分の頭で考えること
よし、とりあえずコードを書いてくれ。 私たちはつい焦って、この指示を出してしまいます。 プロジェクトのスケジュールは常に遅れ気味で、マネージャーからの進捗確認の連絡は容赦なく鳴り響いています。とにかく早く、目に見える形での結果が欲しい。深夜の妙なテンションも相まって、頭の中のモヤモヤをそのままAIに丸投げしてしまう。
しかし、それが最初の罠になります。 Karpathy原則の第一は、勝手な推測をさせず、混乱を隠さず、AIにきちんとトレードオフを提示させることです。
人間同士のコミュニケーションでも全く同じことが言えますが、きっとこういう意図だろうという勝手な推測は、大抵の場合、取り返しのつかない大惨事を引き起こします。人材業界で24年以上、累計1万人以上の方々と面談をしてきた私自身の経験からも、組織内のコミュニケーションのもつれの9割は、この暗黙の了解という名の勝手な推測から始まります。
AIは特に、分かりませんと言うのを嫌がります。人間から大雑把な指示をされると、彼らは足りない前提条件を無理やり学習データから引っ張ってきて推測し、ときにはでっち上げてでも、何かしらのコードを出力しようとします。 AIにとって、空白のまま返答をすることは一種の強迫観念のように耐え難いことなのかもしれません。
たとえば、プロジェクトに新しい決済APIの実装を依頼したとしましょう。 AIはおそらくこのプロジェクトの規模ならこういう高度なエラーハンドリングをするのだろうと勝手に推測して、全く存在しない独自のエラークラスやミドルウェアを新規に定義して組み込んでしまいます。 後からそれを取り除く作業は、ポケットの中で複雑に絡まり合ったイヤホンを解くような、途方もないダルさを伴います。 なんで私は、AIが親切心で勝手に仕込んだコードの依存関係を、文字通り一つずつ紐解いて消しているんだろう。 このやり場のない虚無感こそが、現代の開発者が見えないところで強いられている見えない労働の最たるものです。これがボディブローのように、エンジニアの心を少しずつ削っていくのです。
だからこそ、実装のコードを書かせる前に、AIに対して暗黙の前提を明文化させなければなりません。 焦る気持ちをグッと堪えて、まずはこう打ち込む忍耐が必要になります。
今から決済機能のメイン処理を実装する予定だけれど、まずは必要な前提条件や、あなたがコードを書く上で足りないと思っている情報をリストアップして。 もし複数の実装パターンが考えられるなら、勝手に一つを選ばずに、まずは選択肢としてそれぞれのメリットとデメリットを教えてほしい。
AIという暴走機関車を、一旦立ち止まらせるのです。 えっと、ここの仕様はどうなっていますか、とAI側から質問させる癖をつけさせます。 仕様に不明点があったり混乱したりしている場合は、一旦手を止めて質問すること。この一文を日々のプロンプトに組み込むだけで、あの地獄のような暴走にしっかりとブレーキをかけることができます。
このたった一つの手間が、結果的に午前3時のデバッグ地獄からあなたを救うことになります。 本当の意味での生産性とは、高速でタイピングすることでも、1秒で1万行のコードを生成することでもありません。手戻りを極限まで減らし、精神的な疲弊を防ぐことなのです。
実はこのアプローチに対して、個人の性格タイプによって非常に興味深い反応の違いが出ます。 ソシオニクス的な観点でいえば、ENTpのような発明家タイプの人間は、とりあえず雑に丸投げして壮大に元のコードをぶっ壊してから、なるほどそう動くのかと後から直そうとする傾向があります。まさに昨夜の私そのものです。 逆にISFjのような守護者タイプは、AIが勝手に意図しないファイルを弄ることを極端に恐れるあまり、結局はAIの出力を信じきれずに全部手作業で修正しようとして、必要以上に疲弊してしまいます。
どちらの極端なアプローチも、長期的には組織全体の生産性を著しく低下させます。地方企業が生成AI導入で失敗する3つのパターンの考察の記事でも触れましたが、属人的なスタンスに頼るのではなく、AIに対して適切に質問させるプロトコルをチーム全体で共有していくこと。これこそが、AI導入における見えない失敗を防ぐための防御策となります。
シンプルであることは、すべての技術に勝る
これ、後々あったら便利かもしれない。 これが、エンジニアを蝕む最も恐ろしくてありふれた病の一つです。 そして現代のAIは、この病を重症化させる紛れもない天才だと言えます。
Karpathy原則の第二は、問題を解決するための最小限のコードに留めることです。
AIに対して、ユーザーの権限によって画面の表示を切り替える機能を書いて、と頼むとどうなるでしょうか。高確率で、とんでもなくスケーラブルで、将来やってくるかもしれないあらゆる仕様変更に耐えうるような、巨大で抽象的なコードを嬉々として吐き出してきます。 Factoryパターンを無駄に駆使し、設定ファイルから権限を動的にロードする仕組みを構築し、ガチガチのインターフェースで守られたアーキテクチャ。 ちょっと待ってください。このプロジェクトにはサイト管理者と一般ユーザーの2種類のフラグがあれば、それで十分事足りるのです。
いったいなぜ、AIはここまで無駄に複雑なコードを書きたがるのでしょうか。 それは彼らが、インターネット上の膨大なオープンソースや、大規模で複雑なエンタープライズのプロジェクトを学習のベースにしているからです。彼らは常に、自分が知っている世界最高峰のアーキテクチャをあなたに披露したくてうずうずしています。 GitHubの底なしの海に漂う、今となっては誰もメンテナンスしていない巨大なボイラープレートの亡霊たちが、AIの背後でそっと囁きかけているのです。
しかし、実際の私たちがフロントラインで直面しているのは、そんなシリコンバレーのキラキラしたグローバルプロジェクトばかりではありません。 地方にある中小企業の地味な社内管理ツールだったり、リリース直前で予算が完全に尽きかけていて炎上寸前になっている火の車のようなプロジェクトだったりします。 あるいは、何年も前に書かれたPHPや古いRuby on Railsのコードを、ベテランエンジニアが騙し騙し動かしているような泥臭い現場なのだという現実を見つめるべきです。 毎日の営業データをCSVでエクスポートする機能を追加するだけのことに、分散システムや最先端のPub/Subモデルの統合なんて一切必要ありません。単純なループ処理とファイル書き込みで即日で終わる話です。
たった一度きりのバッチ処理に、無駄な抽象化ややりすぎな設計は百害あって一利なしです。 過剰に柔軟性を持たせた汎用的なコードは、半年後の自分や、そのプロジェクトを引き継ぐ後輩への深刻な技術的負債、つまり呪いとなって重くのしかかります。
さらに厄介なことに、AIが生成したこの過剰に抽象化されたコードは、一見すると非常に洗練されていてプロフェッショナルなものに見えてしまうからタチが悪いのです。 経験の浅い若手エンジニアは、それを見て、おおこれがプロの書き方か、これからはこういうアーキテクチャを採用すべきなんだなと勘違いし、ろくに検証もせずにそのままプロダクション環境に採用してしまいます。
結果として何が起きるか。プロジェクト全体が、誰も全容を把握していない、AIだけが理解できるブラックボックス化された抽象レイヤーで埋め尽くされていくのです。 私たちのコンサルティングの現場でも頻繁に目の当たりにしますが、ここには若手エンジニアとシニアエンジニアとの間に横たわる、致命的な温度差が存在します。 若手は、AIがあっという間に書いた複雑で動くコードを手放しで称賛します。一方でシニアエンジニアは、全体像が見えなくなりメンテナンス不能になった不透明なコードのレビューに、静かな殺意すら覚えるようになります。 このすれ違いが、じわじわとチームのエンゲージメントを削り取り、結果的に離職へと繋がるケースすらあるのです。ツールを入れただけで組織が変わらないのは、こうした人間同士の摩擦を直視していないからです。
だからこそ、私たちはAIにこう問いかけさせなければなりません。 ベテランのシニアエンジニアがこのコードを見たとき、これは複雑すぎる、完全なオーバーエンジニアリングだ、とため息をつかないだろうか。
解決策は驚くほどシンプルです。最優先すべきことは、今目の前にある具体的な問題を、最も短く、最も読みやすいコードで解決すること。 泥水の中でバグをかき分けるような現場においては、美しいスーパーアーキテクチャよりも、誰が見ても1秒で意図が理解できるベタ書きの条件分岐の方が、よっぽど価値がある場面が多々あるという事実を忘れてはなりません。
外科医のような精密さで変更を加える
AIの余計な親切心ほど、既存の安定したプロジェクトを破壊する恐ろしいものはありません。 Karpathy原則の第三は、必要な部分にのみメスを入れ、自分の散らかしたものだけをきちんと片付けることです。
Cursorのインライン編集機能などを使ってファイルを特定して修正させたとき、目的の箇所は見事に修正されているのに、なぜか全く関係のないファイル上部のインポート文の順番が綺麗に整理されていたり、別の関数のコメントが勝手に改善されていたりした経験はないでしょうか。
ついでにコードのフォーマットも整えておきました。 もっとモダンでスマートな書き方があったので、該当箇所とは無関係な部分も一緒にリファクタリングしておきました。
本当に、余計なお世話なのです。 個人開発ならいざ知らず、チーム開発において、影響範囲が不明瞭なついでに行われた変更は致命傷になり得ます。 バージョン管理システムの差分が画面いっぱいに真っ赤になり、レビュアーを務める疲労困憊したシニアエンジニアの機嫌を確実に損ねることになります。
少し想像してみてください。金曜日の夕方です。あと30分でようやく今週の業務が終わって退勤できるという時間に、ふと飛んできたプルリクエストの通知。 若手からの、ちょっとしたボタンの文言修正タスクのはずでした。それなのに、中を開いてみるとAIのついでに行われた親切のせいで、なんと50ファイルもの差分が出ている。 インデントが空白2つから4つに変わっただけなのか、それともその中に勝手にロジックが書き換わっている深刻なバグが潜んでいるのか、結局はレビュアーが一つずつ目視で確認していかなければなりません。
どうして今回のタスクに全く関係ないインデントが全体的に変わっているんだろう。 そんな指摘のコメントを静かに打ち込むたびに、胃がキリキリと痛むのです。あのGitHubの差分タブを開く瞬間の、胸がすっと冷たくなる感覚。あれは何度同じことを経験しても決して慣れるものではありません。
だからこそ、Surgical Changes、つまり熟練の外科医のように極めて精密で限定的な変更が求められるのです。 優秀な外科医は、患部以外の正常な組織を決して傷つけません。開腹手術をするついでだからと言って、頼まれてもいない盲腸を勝手に切除したりはしないのです。メスを入れる範囲は極限まで最小化し、手術が無事に終われば自分が使った道具だけを確実に片付けて去っていく。それがプロフェッショナルというものです。
AIに対しても、同じように厳命する必要があります。 絶対に、指示した箇所以外のコードには1文字も触れないでほしい。フォーマットも変更しないこと。 たとえ既存のコードが古臭くて汚い、あなたの学習データに反していると感じたとしても、そのプロジェクトで長年培われてきたコーディングスタイルに強制的に合わせること。
そして、自分が変更した結果として使われなくなった変数や、不要になったインポートだけを慎重に取り除かせます。 元々存在していた無駄なコードであっても、とりあえずエラーを出さずに動いているのであれば、明示的な指示がない限りは決して触らせてはいけません。 眠れる獅子、いや、どうにか動いているレガシーコードの墓地を、面白半分で掘り起こしてはいけないのです。
これにはもう一つ、心理学的な側面が存在します。いわゆるスポットライト効果の逆転現象です。 我々人間自身がコードを書くときは、誰も俺の細かいリファクタリングなんて気にしていないだろうと高を括り、ついでに色々な場所を弄ってしまう傾向にあります。しかし、他人が書いたコードの予期せぬ変更というのは、レビュアーの目には異常なほど目についてしまうものなのです。
ましてやそれが、AIに任せて自動生成された変更であればなおさらです。 レビュアーは、AIが自分の気付かないところに巧妙に見えないバグを仕込んでいるのではないかという強い警戒心を抱いているため、ただの一文字の修正にすら疑心暗鬼になります。 だからこそ、AIには自分の存在感を完全に消させることを徹底させなければなりません。 AIが書きました、といういかにもなAI特有の匂いがする過度に丁寧なdocstringや、意味不明な空行の追加といった痕跡を、プロジェクト内に残させてはいけないのです。
何をもって成功とするのかを人間が定義する
最後の原則は、おそらくこれらの中で最も重要でありながら、最も実践が難しいものかもしれません。 Karpathy原則の第四は、成功の基準を明確に定義し、それが検証されるまで自律的なループを回させることです。
私たちは何か問題が起きると、よくAIに向かって何も考えずにこのバグを直してと頼んでしまいます。 これは、いったいどのように直すのかというHowの完全な丸投げです。これでは、文脈を持たないAIはあてずっぽうにコードのあちこちを弄り回し、エラーが出なくなった瞬間に直りましたと自信満々に嘘をつきます。そして、大抵の場合は実は裏側で全く別の場所が壊れているのです。
そうではなく、AIに与えるべきはWhat、つまりシステムとして検証可能な成功の基準なのです。 画面が崩れているバグを直して、ではなく。 まずは該当の処理でどのようなデータが返ってくるべきかを定義し、そのバグを再現するためのテストコードを書いて。そのテストを実行して失敗することを確認した上で、テストが通るようにプロダクトコードを修正してほしい。
目標、つまりクリアするべき条件を明確にし、そこに到達するための確実なプロセスを定義する。 さらに、一気に答えを出させるのではなく段階的なステップを設定し、各ステップごとに人間による確認のフェーズを挟むことで、AIが勝手に見当違いな方向へ迷走するのを未然に防ぐのです。
これは、プログラミングの世界で昔から言われているテスト駆動開発の精神そのものです。 私たちは、LLMという魔法のような新しい道具を手に入れたことで、皮肉なことに、かつて先人たちが苦労して構築した基本的なソフトウェアエンジニアリングの原則へと、もう一度立ち返らされているのかもしれません。
まずはテストコードだけを書いて提示してください。私がそれにOKを出したら、実際の修正に取り掛かってください。
この対話の仕方は、組織において人間をマネジメントする手法と本質的には何も変わりません。 とりあえず全部よしなにやっておいて、と言われて期待以上の成果を出せる新人など、どこの世界にも存在しません。地方の中小企業の現場で本当によく見かける、ITに詳しいから君に丸投げでお願いするという組織を崩壊させる地獄の構図と全く同じことを、私たちは無自覚にAIに対してやってしまっているのです。
お互いに目指すべき目標を合意し、マイルストーンを置き、こまめにレビューとコミュニケーションを挟む。 AIを活用する場合も何も違いはありません。彼らは超絶賢い知識の塊ですが、プロジェクト特有のコンテキストを共有するという点においては、圧倒的に自閉的で視座が狭いのです。 だからこそ、我々人間自身がプロジェクトの本当の成功とは何かを泥臭く定義し続け、そこに向かって彼らを駆動させる手綱を、決して手放してはいけないのです。
終わりに：ツールを入れるだけで組織は変わらない
ここまで、Andrej Karpathy氏のガイドラインに基づく、AIコーディングにおける4つの原則を見てきました。
- コーディング前に考える (Think Before Coding)
- シンプルさ第一 (Simplicity First)
- 外科的な変更 (Surgical Changes)
- 目標駆動の実行 (Goal-Driven Execution)
これらを日々の開発で意識し実践すれば、AIが勝手に暴走して環境を根こそぎ壊してしまうような悲劇は劇的に減少するはずです。 午前3時の、あの生きた心地のしない絶望的なデバッグ体験だけは、もう二度とご免です。私がAIに対して静かな殺意を覚える回数も、これで少しは減ってくれるかもしれません。
しかし、ここで最後に一つ、泥臭い現実に立ち返りたいと思います。
これらの原則を個人のエンジニアが深く理解し、手元で実践するのは非常に素晴らしいことです。 ですが、これを組織全体に浸透させ、本質的な生産性の向上に繋げるとなると、話は全く別次元の難しさになってきます。
「THE AI RANK」を運営する私たちAqshは、これまで岩手県をはじめとする多くの地方企業や、文字通り泥水をすするような過酷な開発現場を飛び回ってきました。 そこで私たちが幾度となく目にしてきたのは、今流行りのAIツールたち、たとえばGitHub CopilotやCursor、あるいはDifyなどを使った社内AIシステムを、何百万円という高額な費用をかけてポンと導入してみたものの、結局のところ一部のITリテラシーの高い若手社員しか使っていないという、非常に残酷で虚しい光景です。
AIツールを入れたからといって、勝手に組織がDX化されるわけではありません。
プロンプトエンジニアリングの研修ならやりましたよ。 全社向けの使い方のガイドラインも策定して配りました。 それだけで現場が魔法のようにAIを使いこなし、売上が上がるのであれば、誰もこんなに苦労はしていません。そもそもプロンプトなんていう横文字の概念すら、地方の多くの中小企業の現場には全く浸透していないというのが、隠しようのないリアルな現実なのです。
本当に必要なのは、シリコンバレー生まれのキラキラしたツールを導入して満足することではなく、そのツールを使う人間の心と、組織の解像度を徹底的に上げることです。 なぜ、あの優秀なベテラン社員は意地でもAIを使おうとしないのか。 なぜ、若手社員はAIの出力結果を一切疑わずに、そのまま本番環境にデプロイしようとするのか。
そこには、人間特有の不安、これまで培ってきたプライド、新しいことを学ぶ怠慢、あるいはチーム内にある修復の難しい温度差が存在しています。 AqshがAIコンサルティング事例でもお見せしているAIエージェント構築と伴走支援というサービスは、単なる便利なシステム開発ではありません。 ソシオニクス的アプローチを取り入れた組織分析と性格プロファイリングを踏まえ、その企業、そのチームに渦巻く人間の感情の泥臭さに真正面から向き合いながら、ゆっくりと、しかし確実に無理なくAIを定着させていくプロセスそのものなのです。 AIエージェントを作る前に、まずは人間の解像度を極限まで高める作業が必要不可欠になります。
もし今、あなたが所属するチームのAI活用に限界や閉塞感を感じているのなら。 あるいは、部下がAIに書かせた壮大すぎるオーバーエンジニアリングのコードのレビューに、毎日疲弊しているのなら。
まずは、あなた自身の現在地を客観的に知ることから始めてみてはいかがでしょうか。
**『THE AI RANK いわてのAIスキル診断』**は、単なるプロンプトの知識を問うだけのテストではありません。 あなたがAIとどう向き合っているか、そして組織の中でどのような立ち位置にいるのかを客観的に可視化するためのツールです。
AIの暴走を防ぐ最大の鍵は、最終的にはツールの性能ではなく、私たち人間のスタンスに他なりません。 深夜の終わらないデバッグから解放され、本当に価値のある、人間らしい仕事にあなたのリソースを集中させるために。 泥臭い現場の痛みを乗り越えて、真の意味でAIをチームの力に変えるために。
ぜひ一度、あなたのスキルを測ってみてください。 岩手県をはじめとする地方企業で、AIエージェントの構築や組織全体のAI定着に課題を感じている方は、岩手法人向けのAI導入支援ページもご覧ください。
私と同じように、午前3時に冷め切ったマックフライポテトの匂いと共に絶望する夜が、一つでも減ることを心から願っています。
