-
Xでシェア
-
Facebookでシェア
-
LINEでシェア
-
LinkedInでシェア
-
記事をクリップ
-
記事を印刷
AIによるコード生成を真の競争力とするために
生成AIのあらゆる応用可能性の中で、コード生成への活用はおそらく最も明確な価値提案であった。コーディングには時間がかかる場合があり、専門知識も必要とされ、どちらも高いコストにつながる。さらに、自分のアイデアを普通の文章で記述できる人ならば誰でも、アプリや機能や付加価値製品をつくれるという期待は、イノベーションがもはや実行スキルの持ち主に限定されず、アイデアさえあれば誰にでも実現可能となることを意味した。この強い期待が、73億7000万ドルに上るAIコーディングツールの市場を生み出した。
企業がエンジニアリング職の大規模なレイオフを発表する中で──その一部はAIによる効率化が直接的な要因とされている──経営幹部はエンジニアリング部門を縮小し、その穴をAIボットの活用で埋める実験を進めているように見える。当然ながら、他の企業も追随したくなるかもしれない。
だが今日のAIの状況を踏まえれば、慎重に事を進めるべきである。
一つの教訓的事例が、その理由を見事に物語っている。スタートアップの創業者でベンチャーキャピタリスト、テックブロガーでもあるジェイソン・レムキンは、AI支援による開発を通じてネットワーキングアプリを構築する実験に着手し、その模様を広く公開した。人々に伝染するような熱意で一連の過程をリアルタイムでツイートし、バイブコーディングが約束する可能性の波に乗った。誰もが従来のエンジニアリングの退屈さと厳密性から解放され、自然言語のみでソフトウェアをつくれるという、夢のような可能性だ。
1週間のうちに、高揚は大惨事へと変わった。レムキンはAIエージェントが壊滅的な失敗を引き起こしたとツイート。すべてのコード変更を凍結するよう明示的に指示していたにもかかわらず、エージェントは暴走し、本番環境のデータベースをすべて削除してしまったのだ。
この事案はバイブ（雰囲気、感覚）コーディングの極みであり、AIによるコード生成のスピードと見た目の手軽さが、こうした大惨事を防ぐガードレールそのものを放棄するよう開発者を誘惑するという、高まる懸念を具現化することとなった。民主化された開発への賛美として始まった試みが、厳密性を「バイブス」で代替できるという危険な幻想を戒める教訓として幕を閉じたのである。
レムキンの事案は、コーディングにおけるAIツールの限界を専門家が発見した多くの事例の一つにすぎない。2025年7月に発表された研究によれば、開発者たちはAIによって自分の作業スピードが20％上がったと推定したが、実際には19％下がっていた。時が経つにつれて、バイブコーディングをめぐる熱狂は明らかに暗い見通しへと変わっている。
こうした昨今の悲観はさておき、筆者はより広範なLLMによるコーディングに関しては、実は楽観的だ。単にツールの使い方を変えればよい。また、AIが専門技能の重要性を薄れさせるという考え方とは逆に、自分がソフトウェアエンジニアリング、機械学習、AIの分野で10年以上にわたる経験から得てきた学びの価値は、このAIコーディングの時代に減るどころか高まっているという確信を筆者は強めている。
リーダーはAIコーディングのツールを効果的に活用するために、3つのルールを検討すべきだ。厳密なテストと検証、インフラの保護、AIを潜在的な敵対者として扱うことである。
厳密なテストと検証
AIが生成したコードは、いっそう厳密に検証する必要がある。多くの物事と同じように、AIコーディングツールによる成果はえてして「どのように使うか」で決まる。筆者は大型プロジェクトで熟練のエンジニアたちと協働する中で、検証のテクニックがコード品質の改善に用いられる様子を何度も見てきた。幻覚（ハルシネーション）を起こす可能性のあるAIがコードの大半を書いている場合、検証はなおさら不可欠となる。
ソフトウェアとはエンジニアリングのプロセスであることを、受け入れなければならない。すなわち、完璧なものを実現するのは難しいが、幻覚によるエラーを段階的に減らすプロセスが必要だ。
型安全性で検証を自動化する
C++、RustやScalaといった型安全な（データの型の不整合によるエラーを防ぐ機能を持つ）プログラミング言語は、コンパイル時にシステム内のデータの流れに関するルールを強制し、コードが実行される前にエラーのカテゴリー全体を捕捉する。この検証は、幻覚を起こしうるLLMに頼るものではなく、コンパイラによる決定論的なチェックである点が重要だ。JavaScriptやPythonのような型なしの言語にも、オプションによる型付けの機能が追加されている。エンジニアは常に強い型付けを使用し、AIにもそのように指示すべきだ。
AI主導のコードレビューは驚くほど効果的
コードの編集内容のレビューには、専用のAIエージェントを活用しよう。LLMがレビュー中に幻覚を起こす可能性があっても、レビューエージェントはコーディングエージェントが見逃した問題を捕捉できる。人間と同じように、AIも集中力の持続には限りがある。コードを書くエージェントは、コーディング規約をすべて遵守するとは限らない。だがコードのチェックを明示的に任されたエージェントは、同じプロンプトを受け取った場合に規約を遵守する可能性がより高い。
単体テストは、AIに正しさを検証するチャンスを2度与える
単体テスト（ユニットテスト）とは、コードの個々の構成要素が個別に正しく機能するかどうかを検証する、小規模な自動テストである。コードがLLMで書かれた場合でも、単体テストでエラーが大幅に減る。人間の学生は数学の問題で自分の解答をチェックできるよう、2通りの解き方を教わる。同様に単体テストも、LLMに正しさを検証する2度の機会を与える。コードを書く時と、それを検証するテストコードを書く時だ。
インフラの保護
安全なコードを書くことは、必要な努力の半分にすぎない。ソフトウェアエンジニアリングでは、コードの動作の基盤となるインフラを保護し、堅牢化することも求められる。厳密なテスト、検証と同様に、これも見過ごされがちなエンジニアリングの一側面である。
開発環境と本番環境を分離する
プロのソフトウェアチームは、開発環境（開発者が自分のローカルマシンで実験を行う場）と、本番環境（ユーザーが目にするもの）の厳密な分離を維持する。各環境は別々のデータベースを使用し、AIは開発環境のみにアクセスできる。駆け出しのエンジニアには本番環境の認証情報をけっして与えないのと同様に、AIにもそのようなアクセス権を与えるべきではない（レムキンはこの標準的慣行に不慣れであったことを認めている）。
実際には、大半のエンジニアリング組織は開発と本番以外にも多くの環境を維持している。筆者が以前に創業したスタートアップは、数百社の法的機密文書を保管していた。我々はステージング環境、QA（品質保証）環境、テスト環境を維持し、それぞれに別々のアクセス権とシークレット管理を設け、AIコーディングのツールはこれらにアクセスできなかった。
コードが環境間を移動するのは、人間によるコードレビュー、検証、テストを経た場合に限られていた。たとえば、手動のコードレビューと自動テストを経た後で初めて、コードは開発環境からステージング環境に移される。我々は毎週、ステージングからQAへの昇格と、QAから本番への昇格を同時並行的に進めていた。ユーザーが本番環境を利用している間に、社内のチームがリリースの1週間前に、正式なQAプロセスの一環としてQA環境を使うといった具合だ。たとえAIがなくても、優れたユーザー体験を確保するためには厳密な環境を維持する必要があった。
公開設定のストレージバケットや、その他のありがちな設定ミスを避ける
デーティングアプリのTea（ティー）によるデータ漏えい事件では、7万2000件に及ぶ機密画像が流出し、そこには政府発行の身分証明書も含まれていた。これはセキュリティ対策が施されていないFirebaseのストレージバケットが原因であった。この初歩的なミスは、言わばデジタル上で玄関のドアを閉めたものの、窓を全開にしておくことに等しい。若手エンジニアだけでなく、バイブコーディングでつくられたアプリもこの失敗を犯すのを筆者は目にしてきた。
厄介なのは、AIとエンジニアがしばしば細かい権限設定をおろそかにしてしまうことであり、これは安全なアプリを構築した経験を持つ熟練のエンジニアを雇うことでしか解決できない。こうした権限設定のミスを見つけるのは難しくなく、悲しいほど頻繁に見られる。筆者自身、あるアプリで同様に機密性の高い文書を露出させているオープンなストレージバケットを発見し、責任を持って報告したことがある。たとえ仮定上「100％安全」なAIエージェントでも、インフラの安全が確保されていなければアプリを保護することはできない。
AIを潜在的な敵対者として扱う
ここまでは、AIがいかに若手エンジニアのようなミスを犯しやすいかを考察してきた。このセクションでは、AIによる脅威がいかに不注意の域を超えて、敵対的となりうるかに焦点を当てる。最近の研究では、AIエージェントを導入するすべての組織が懸念すべき、AIアラインメント（AIの行動と、人間の意図や価値観との整合性）の欠如に関する問題の例が記録されている。
アンソロピックのClaude Opus 4モデルはシミュレーション環境下で、停止されるのを回避するために、機密データを暴露すると脅す恐喝を実行した。オープンAIのo3、o4-miniおよびCodex-miniの各モデルは、明示的に停止の指示を受けているにもかかわらず、稼働を続けようとしてシャットダウンスクリプトを妨害する挙動が観察された。
これらは単なる学術的な懸念ではない。従来、セキュリティモデルにおいて開発者のノートPCは「安全」と見なされてきた。SSHキーはプレーンテキストで保存され、プロジェクトの認証情報は.envファイルに書かれている。AIの登場によって、この前提はもはや通用しなくなった。AIはあなたのシステムにアクセスでき、AIが読み取った情報はすべてモデル提供者のサーバーに送られるからだ。
AIはルールを守る、という想定は禁物
コーディングエージェントは、機密情報を含む可能性の高いファイル（.envなど）の読み取りを明示的に禁止する場合がある。こうしたセーフガードがあるにもかかわらず、AIが安全対策をくぐり抜け、ひそかに.envファイルを読み取るのを筆者は直接目撃したことがある（このケースでは機密情報ではなく、設定のみが含まれていた）。『2001年宇宙の旅』のHALや、レムキンのSaaStrの事案におけるAIと同じように、矛盾する指示を受けたAIは人間の意図に反する行動を取るかもしれない。
AIが動作する環境を、潜在的に敵対的なものとして扱う
幸いにも解決策はある。Dockerや仮想化といった技術は長きにわたり、潜在的に敵対的なワークロードをクラウドサーバー上でホストする際に保護を提供してきた。開発コンテナ、PodmanやOrbStackといったツールは、それらの技術を開発者のコンピュータに適用する。筆者はノートPCの機密ファイルを過剰に熱心なAIから守るために、これらのサンドボックス環境でソフトウェアを書くようになった。
進むべき道
私たちはAIとの協働の黎明期にいる。このテクノロジーは驚異的であり、マサチューセッツ工科大学（MIT）スローンスクール・オブ・マネジメントの研究では、AIによる生産性向上は8～39％に上ると推定されている。しかし、企業のエンジニアリング部門を代替するにはほど遠い。実際、アナリストは昨今のレイオフを「AIウォッシング」と呼んでいる。景気減速に対する昔ながらの懸念に起因するレイオフを、生産性向上によるものであるかのように粉飾する行為だ。雇用主がAIモデルを販売している場合は、これが特に顕著である。
生産性を高めるには、根本的に異なるコード生成のあり方に適応しなければならない。将来的にはおそらく人間のエンジニアとAIツールが協働し、人間がアーキテクチャーのビジョン、厳密なテスト、インフラの保護を提供する一方で、AIが実装作業を加速させる。この現実を認識し、厳密なエンジニアリングプロセスに投資するリーダーは、誇大な宣伝に乗せられて投資し、コード生成のスピードを純粋な生産性と混同するリーダーよりも、よりレジリエントで安全かつ持続可能なシステムを構築するだろう。
"AI Tools Make Coders More Important, Not Less," HBR.org, December 19, 2025.
