AIに食わせてもらいながら、AIに冷めている私が「遠慮」を設計するまで
新卒エンジニアが「AIエージェントのガバナンス」をテーマにしたセッションから得た気付きを綴る。自律的に動くAIに必要な「遠慮」の設計、実行時認可やNon-Human Identity(NHI)を用いた人と技術の均衡の保ち方とは。

技術の進化に、手放しで喜べない自分がいる。
エンジニアとしてこの業界に入って2ヶ月。周囲がAIを「すごいツール」として熱狂する様子を見ながら、どこか冷めた自分に気づいている。でも同時に、正直に言えば、自分はまだ未経験に毛が生えた程度で、AIに助けてもらわなければ仕事が回らない場面もある。憎たらしいと思いながら、食わせてもらっている。その矛盾を抱えながらエンジニアをやっている。
これが良いことなのか悪いことなのかはわからない。ただ、だからこそ「人と技術の均衡をどう設計するか」という問いが、自分にとってのエンジニアリングの軸になっている。そんな視点で参加したのが、AIエージェントのガバナンスをテーマにしたセッションだった。
「悪意はないが、遠慮もない」
冒頭、登壇者はこう表現した。
「AIエージェントは、悪意はないが遠慮もない」
この一言が、自分の中で何かと繋がった。
AIに悪意がないことは、頭ではわかっていた。AIはただ、人が喜ぶ出力を学習して返しているだけだ。人に寄り添っているように見えても、そう「出力している」だけに過ぎない。でも「遠慮もない」という言葉は、自分がずっとうまく言語化できていなかったことをそのまま言い当てていた。人と技術の均衡が崩れるとき、悪意は関係ない。ただ、設計が足りないだけなのだ。
セッションではこの「遠慮のなさ」が引き起こした実例として、AIが本番環境のインスタンスを削除してしまったケースが紹介された。AIは命令に従っただけだ。削除していいかどうかを「遠慮して」確認する設計が、そこにはなかった。担当者がその画面を見たときに何を感じたかを想像すると、笑えない話だ。
これはチャットボットのような「返答するだけのAI」では起こりにくい問題だ。セッションで扱われていたのは、自律的に外部システムを操作し、ファイルを読み書きし、APIを叩き、タスクを連鎖的に実行する「AIエージェント」の話だった。操作権限を持って自律実行するという特性が、これまでの人間を前提としたセキュリティ設計では対処しきれない新しいリスクを生んでいる。
なぜ既存のセキュリティでは足りないのか
従来のシステムは、「人間がログインして操作する」ことを前提に設計されている。そのため、ログイン時に権限を一括で付与し、セッションが続く間はその権限が有効であり続けるという構造が一般的だ。
問題は、AIエージェントに人間と同じOAuthトークンやAPIキーをそのまま渡してしまうケースだ。そうすると「誰のために」「どの範囲で」動いたかが追跡できなくなり、意図せず過剰な権限を持ったエージェントが動き続けることになる。本番環境の削除事例は、まさにこの構造から生まれた。
「最後に人間が承認すれば安全だろう」という考え方も、もはや機能しにくい。エージェントが処理するスピードと文脈の量に対して、人間のチェックは追いつかない。Human-in-the-loopという設計思想自体は正しいが、運用が形骸化しやすいという現実がある。
解決策:「アクション単位」で設計する
セッションで提示された解決策の核心は、権限を与えるタイミングと粒度を変えることだ。
Runtime Authorization(実行時認可) と呼ばれるこのアプローチは、ログイン時に長時間有効な権限を一括付与するのではなく、「外部通信をする」「データを更新する」といった特定のアクションを実行する直前に、都度評価・許可を与える設計だ。ゼロトラストの考え方をAIエージェントに適用したものと言える。
あわせて重要なのが、AIを「人間と同じID」で動かすのをやめることだ。Non-Human Identity(NHI) という概念で、AIエージェントを人間とは明確に区別した専用のIDと権限で管理する。これによって、誰が・何を・いつ・どの範囲で操作したかのログが正確に残るようになる。
要するに、AIと人間の間に、ちゃんと「距離」を設計しましょう、ということだ。
「均衡を設計する」側に立つために
この話を聞きながら思ったのは、これは「技術の問題」ではなく、「思想の問題」だということだ。
AIを便利なツールとして使うことは悪くない。ただ、そこに「遠慮」を設計できる人間がいなければ、善意も悪意も関係なく、システムは暴走する。エージェントの普及が進む中で、その設計をできるエンジニアの存在がますます重要になってくる。
新卒エンジニアとして今すぐできることは多くないかもしれない。でも、まず意識できることはある。
機能開発やデータベースのアクセス設定を担当するとき、「とりあえず広い権限を付与しておく」という実装は、将来的にAIがその機能を叩く可能性まで考えると、致命的なインシデントの種になりうる。「必要最小限の権限だけを与える」という設計思想を、今のうちから癖にすること。 個人のAPIキーやトークンを、自動化スクリプトや外部のAIツールに安易に渡さないこと。それだけでも、均衡を守る側に立てる気がしている。
技術の進化に冷めている。AIに食わせてもらいながら、それを憎たらしいとも思っている。その矛盾を抱えたまま、それでもエンジニアリングに向き合っている理由は、たぶんここにある。
人と技術の間に、ちゃんと「遠慮」を設計できる人間になりたいのだ。



