みなさん、こんにちは。
先週、セキュリティコンサルタントをしている知人と「AIによるコード生成」について議論する機会がありました。
彼の主張は専門家としてごく自然なものでした。
「コード生成をAIに任せるなんて、セキュリティ上許容できないよ。もしAIがブラックボックス化した間違ったコードを出力しても、AI自身は責任を取れない。結局、最終的な責任を負うのは人間なんだから。」
セキュリティを守る立場としては、まさに仰る通りです。しかし、『責任が取れないから任せられない』という理屈は本当に通るのでしょうか。
「……それって、部下に仕事を任せる場合と何が違うのだろう？」
たとえば、部下が書いたコードに重大な脆弱性が見つかったとします。だからといって、顧客に対して「このコードを書いたのは担当の◯◯なので、彼に責任を取らせます」なんて対応をする会社はありませんよね。当然、プロジェクト責任者や会社が責任を負います。
それでも私たちは、日常的に部下へ仕事を任せています。
ではなぜ、AIだけが「責任を取れないから任せられない」と言われてしまうのでしょうか？
今回は、この違和感を端緒に「AIに仕事を任せるとは一体どういうことなのか？」をじっくり考えてみました。
「AIと人間は違う」からこそ、リスクで考える
ここで必ず出てくるのが、「AIと人間は根本的に違うのだから、部下と同列に語るな」という反論です。
この指摘はまったくもって正しく、ぐうの音も出ません。
AIにはハルシネーション（幻覚）があります。動くコードが出力されたとしても、仕様を満たしているとは限りませんし、既存システムとの整合性を欠いていたり、脆弱性を潜ませていたりすることもあります。一方、人間のエンジニアには経験や専門知識があり、意図や根拠を問い詰めることも可能です。
「AIと人間は同じだから、部下と同じ扱いでいい」なんて暴論を通すつもりはありません。
しかし、「違いがあるから、AIには一切任せられない」という結論になるのも極端です。
一晩じっくり考えて導き出した結論は、「AIだから危険」ではなく、「失敗したときのリスクの大きさで任せる範囲を設計する」というアプローチでした。
重要なのは、作業の主体が人間かAIかではなく、「その作業が失敗したときにどれだけの損害が出るか」です。
たとえば、同じ「コードを書く」作業でもリスクは様々です。
- 開発環境のコードを変更する / テストコードを書く / ドキュメントを作る
- 本番データを操作する / 本番環境へデプロイする
前者は失敗しても元に戻せますが、後者は一発アウトになりかねません。
つまり、「AIが書いたから人間が全件確認する」のではなく、「失敗時のリスクが大きいから人間の関与を強める」と考えるのが自然なのです。
「人間が全件レビューすれば安全」という幻想
いま現場で起きている深刻な問題は、AIの導入によって「人間のレビュー量」が爆発していることです。
- AIが爆速でコードを書く
- 人間がそれをレビューする
- AIがさらにコードを書く
- 人間のレビュー待ちが積み上がる
生産性を上げるためにAIを導入したはずなのに、人間のレビューが最大のボトルネックになっています。しかも、人間は大量の確認作業を高い精度で長時間続けられるようにはできていません。レビュー件数が増えれば増えるほど、確認は雑になり、重要な見落としが増え、「見たことにして承認ボタンを押す」という形骸化が進みます。
「人間が最終確認しているから安全だ」という前提そのものが、すでに崩壊しつつあるのです。
優秀な上司は、部下の仕事を「全件レビュー」しない
ここで、最初の「部下」の話に戻りましょう。
優秀なマネージャーは、部下が作った資料の一字一句、コードの全行をチェックしたりはしません。部下のスキルとリスクの大きさを天秤にかけ、「ここまでは任せる」という権限のラインを引き（デリゲーション）、自律的に動いてもらいます。
- 通常の問い合わせ対応や技術的な実装方法は任せる
- 少額の費用発生や仕様変更は任せる
- 契約内容の変更や重大なクレームは即座に報告させる
これは部下を100%盲信しているからではなく、「失敗したときに自分が許容できるリスクの範囲」を把握した上で権限を与えているからです。
このアプローチは、AIエージェントの活用でもまったく同じです。
- 自律的に任せる
コード生成、リファクタリング、テストコード作成、静的解析、ドキュメント生成 - 条件付きで任せる
Gitへのコミット、PRの作成、パッケージの追加、CI/CDの実行 - 人間の承認を必須とする
本番環境へのデプロイ、DBの破壊的変更、セキュリティポリシーの変更
人間が個別の操作を張り付きで監視するのではなく、AIが行動できる「枠組み（境界）」を設計する。これこそが、これからのAI活用の核心です。
「Human in the Loop」から「Human in the Governance」へ
これまでAIの安全対策としては、AIの判断ごとに人間が割り込む「Human in the Loop」（個別の成果物を人間が確認・割り込む形式）が主流でした。しかし、すべての処理でこれを行うと、人間の処理能力が全体の限界を決めてしまいます。
そこで今求められているのが、「Human in the Governance」（AIが動く境界線やガバナンスを人間が設計する形式）という考え方です。
人間はひとつひとつの出力結果を検品するのではなく、AIの「目的・与える権限・制約・閾値・エスカレーション条件・緊急停止条件」というガバナンスの枠組みを設計します。
AIはその枠組みの中で自律的に動き、境界を越えそうになったときだけ人間を呼び出す。これなら、安全性を担保しつつAIのスピードを活かしきることができます。
ブラックボックスであることを前提にシステムを組む
「でも、AIは内部の判断根拠が分からないブラックボックスだから怖い」という意見もあります。
これも事実ですが、実のところ人間だって完全なホワイトボックスではありません。「なんとなく過去の経験で」「前もこう書いたから」と感覚で実装しているケースは多々あります。
ブラックボックスだからといって遠ざけるのではなく、「ブラックボックスであることを前提に、どれだけの権限なら与えてよいか」を設計するのがエンジニアリングです。
間違えてもすぐロールバックできる作業なら高い自律性を与え、不可逆で致命的な作業なら人間の承認を必須にする。
「AIが信用できないからこそ、リスクをコントロールできる仕組みをつくって任せる」のです。
AI時代の責任は「何を任せたか」に宿る
「AIは責任を取れない」
この言葉は正論ですが、だからといって「任せられない」理由にはなりません。
組織の本質は、責任を負う人間が権限を委譲し、境界を越えた問題だけを吸い上げる構造にあります。AIを活用する組織もまったく同じ構造で運用できます。
そう考えると、AI時代において、システム開発の現場における人間の責任のあり方は変わります。
これまでは「誰がこのコードを書いたのか？」が問われていましたが、これからは「なぜそのAIに、その権限を与えたのか？」が問われるようになります。
- なぜ本番環境へのアクセス権を与えていたのか？
- なぜ人間の承認スキップを許可したのか？
- なぜそのリスクを許容できると判断したのか？
AIの判断そのものに責任を持つのではなく、「AIに与えた自律性の範囲」に責任を持つ。これこそが、これからの時代に人間に求められる覚悟です。
全件レビューはもう止めませんか？
AIによってコードが爆発的に生成される時代において、「人間が根性で全部レビューする」という力技はいずれ破綻します。
これからの開発者に求められるのは、「どこまでを自動化し、どこからを人間が判断するか」というレビューの境界線をデザインする管理能力です。もちろん「コードを吟味するレビュー力」も求められますが、すべてをレビューする前提は放棄すべきです。
人間も間違えます。AIも間違えます。
大切なのは、「どちらが正しいか」を競うことではなく、「間違えてもシステム全体としてカバーできる仕組みになっているか」です。
AIをどこまで信用するかではなく、どこまで任せられるように設計できるか。
AIに使われるのでも拒絶するのでもなく、優れたマネージャーのようにAIと協働していきたいものです。
「AIと人間の境界線をデザインすることの大切さはわかるが、クリティカルな場面でブラックボックスなAIは使いたくない」——そう感じている方も少なくないはずです。私自身、AIをフル活用していますが、クリティカルな場面ではブラックボックスなAIを妄信せず、説明可能性を重視しています。
ビューローみかみでは、構想段階の壁打ちからPoC・実装・現場導入まで、医療・介護の現場で「使い続けられる」ものづくりを支援しています。
カメラ・マイク・各種センサーで現場を「見て・聴いて・感じて」判断する仕組みを、なぜその判定になったのか説明できる形でご提供します。
▶ AIカメラ・センシング開発サービスの詳細はこちら
気になることがあればお気軽にご相談ください。
本日も最後までお読みいただきありがとうございました。
それでは、よいAIライフを！
