がんじがらめの現場で、AIはどこまで使えるか
（おことわり 機密保持のため実話を編集して内容を改変しています）
あるエンジニアのブログで、こんな話を読みました。
金融系の大規模システム開発に参加していたとき、法律の改正に対応するための修正作業を担当したことがある。何ヶ月もかけてアセスメントし、影響範囲を調査し、テストを重ねた。そのすべての作業の結果として、本番コードに加えた変更は、if文を2箇所に追加しただけだった。
もう一つ、別の話も読みました。そのプロジェクトでは、使えるツールに厳しい制限があった。SlackもGitHubも、自分たちが普段使っているものは持ち込めない。何かをインストールするには申請が必要で、承認には時間がかかる。だから、便利なツールを使いたければ、こっそり使うことになる。
この2つの話は、日本のソフトウェア開発が抱える構造的な問題を、非常にコンパクトに表しています。
発注側から見ていた風景
私はエンジニアではありません。翻訳会社に在籍していた時代、システム開発の発注側として関わった経験があります。ベンダーと要件を詰め、仕様書をやりとりし、納品物を検収する。そういう立場です。
発注側から見ると、多重下請構造は「効率的な分業」にも見えます。大きなプロジェクトを小さく切り分けて、専門の会社に任せる。リスクを分散し、責任を明確にする。合理的な仕組みのようにも思えます。
でも、内側にいた人たちの話を聞くと、全く違う景色が見えてきます。
情報は上から下に流れるとき、毎回翻訳され、削られ、歪む。現場のエンジニアは、なぜその仕様になっているのかを知らない。発注側は、現場で何が起きているかを知らない。そのギャップを埋めるために、膨大な文書と会議と確認作業が生まれる。
そしてその構造の中で、エンジニアたちは「与えられた仕様を、与えられたツールで、与えられた手順で実装する」ことだけを求められる。考えることよりも、従うことが評価される。
if文を2行追加するだけの作業に、何ヶ月もかかるのは、技術的な問題ではなく、構造的な問題でしょう。
「こっそり使う」が意味するもの
ツール制限の話に戻りましょう。
金融系のシステム開発では、セキュリティ上の理由から、使用できるツールが厳しく制限されています。これ自体は理解できます。顧客の財産や個人情報を扱うシステムですから、外部サービスへのデータ漏洩リスクは慎重に管理されなければならない。
ただ、問題はその管理の仕方にあります。
「リスクを評価して、安全なものは使えるようにする」ではなく、「とにかく禁止する」という方向に向かいやすい。承認プロセスが重すぎて、現場のニーズに対応できない。結果として、エンジニアたちは必要なツールを正規のルートで入手できず、非公式に使うという選択をします。
これは個人の問題ではありません。構造が生み出す行動です。
制約が厳しすぎると、人はルールを迂回することを覚えます。表向きは承認されたツールだけを使い、実際には別のものを使う。二重構造が生まれる。透明性が失われる。それは組織にとって、ツールを自由に使わせることよりもはるかに大きなリスクになりえます。
そういう環境で、バイブコーディングやClaude Codeは、どう位置づけられるのでしょうか。
バイブコーディングが活きる場面、活きない場面
正直に言えば、大規模・多重下請の現場でバイブコーディングをそのまま持ち込むことは、難しいと思います。
活きにくい理由は明確です。
まず、ツール制限の問題があります。Claude CodeはインターネットにアクセスするAIツールです。金融系の閉じたネットワーク環境では、そもそも使えない可能性が高い。承認を取ろうとしても、「AIに社内コードを見せることへのリスク」という壁に当たります。
次に、変更の自由度の問題があります。バイブコーディングの本領は、試行錯誤にあります。AIにコードを書かせ、動かして確認し、修正して、また試す。このサイクルを速く回すことで価値が生まれます。でも「動作しているシステムは修正できない」「変更には何ヶ月もかけた検証が必要」という環境では、そのサイクルを回す余地がありません。
そして、責任の所在の問題があります。AIが生成したコードに問題が発生したとき、誰が責任を取るのか。多重下請構造は、責任の連鎖を明確にすることで成り立っています。AIという「責任を取れない存在」が生成したコードは、その連鎖に組み込みにくい。
しかし、活きる場面も確実にあります。
ここが、私がこの問いを考えていて、最も面白いと思った点です。
制約の多い環境ほど、AIが補える余白が実は多いのです。
制約の中にある「余白」
大規模開発の現場では、エンジニアの時間の多くが、コードを書くこと以外に使われます。
仕様書を読んで理解すること。既存の巨大なコードベースを調査して、影響範囲を把握すること。テストケースを作成すること。ドキュメントを書くこと。レビューコメントに対応すること。
これらは「コードを書く作業」ではないので、ツール制限の対象になりにくい場合があります。テキストを処理するAIツールとして使うなら、社内コードを直接渡さずに使える場面も多い。
具体的に考えてみます。
仕様書の理解と整理。100ページある仕様書を読み込んで、「この変更によって影響を受ける可能性がある箇所を列挙してください」とAIに問うことができます。コードを渡さなくても、仕様の論理構造を分析させることはできます。
テストケースの設計。「この条件のシステムに、法律Xの改正が加わった場合、考慮すべきエッジケースを列挙してください」という使い方は、コードを一切渡さなくても有効です。人間が見落としやすいケースを洗い出すのに、AIは非常に有効です。
ドキュメントの生成。コードの変更が確定したあと、その変更内容を説明するドキュメントを書く作業は、多重下請の現場では非常に重要です。変更理由、影響範囲、テスト結果の要約。こうした文書生成は、AIが最も得意とする領域の一つです。
コードレビューの補助。レビュアーとして参加している場合、変更されたコードをAIに渡して「このコードに潜在的なリスクはあるか」と問うことができます。ただし、これはセキュリティポリシー次第です。
そして最も重要な使い方が、個人の学習と準備です。
「こっそり使う」を「堂々と使う」に変える道
ツール制限の現場で、エンジニアたちがAIツールをこっそり使っているとしたら、それはすでに起きていることだと思います。ChatGPTでコードの問題を解いたり、Claudeに設計の相談をしたり。自分のPCで、業務時間外に、あるいは業務コードを渡さない形で。
これは止められません。そして止める必要もないと、私は思っています。
むしろ問うべきは、「どうすれば、それを安全に、公式に、チーム全体で使えるようにできるか」です。
そのためのアプローチとして、いくつかの方向性が考えられます。
ローカルで動くAIモデルの活用。クラウドのAPIではなく、社内のサーバーや個人のPCで動かせるオープンソースのLLMを使えば、コードが外部に出ません。金融系の閉じた環境でも、承認を取りやすくなります。
AIの用途を「生成」から「分析・説明」に限定する。コードを書かせるのではなく、コードを説明させる、リスクを列挙させる、ドキュメントを整理させる。こうした用途は、セキュリティリスクが相対的に低く、承認を取りやすい。
小さな実績を積み上げる。いきなり「AIを使った開発フローに変えましょう」ではなく、「このドキュメント作成タスクにAIを使ったら、2時間が30分になりました」という実績を一つ作る。組織の中でAI活用の信頼を少しずつ積み上げる。
これは遅く見えて、実は最も速い道だと思います。
if文2行の先にあるもの
法律改正への対応でif文を2行追加するだけの作業に、何ヶ月もかかる。この話が笑えないのは、そのエンジニアの時間とエネルギーの大半が、2行のコードを書くこと以外に使われているからです。
影響範囲の調査。承認フローの通過。テスト環境の準備。レビューの実施。本番適用の手順書の作成。
これらのプロセスの多くは、AIが補助できます。完全に自動化はできなくても、各ステップにかかる時間を半分にすることは、十分に現実的です。
何ヶ月かかっていた作業が、何週間になる。それだけで、エンジニアの体験は大きく変わります。「やっとコードを書けた」という達成感ではなく、「調査と準備が速く終わったから、コードの品質に集中できた」という感覚に変わる。
バイブコーディングの本質は、コードを速く書くことではありません。考えることに集中できる環境を作ることだと、私は理解しています。
多重下請の現場でも、その本質は変わりません。制約の中で、AIが補える余白を探す。その余白を少しずつ広げていく。それが、がんじがらめの現場でAIを活かす、現実的な道筋だと思います。
まとめ
大規模・多重下請の開発現場に、バイブコーディングをそのまま持ち込むことは難しい。でも、活きる場面は確実にあります。
コードを書く場面ではなく、コードを書く前と後の場面。仕様の理解、テストの設計、ドキュメントの生成、レビューの補助。そして何より、個人が学び、準備し、考えを整理するための道具として。
制約の多い環境だからこそ、AIが補える余白が多い。この逆説は、多重下請の現場に限った話ではなく、あらゆる「変えにくい環境」で働く人たちへのヒントになるかもしれません。
こっそり使わなくていい環境を作ること。それが、次のステップだと思います。