生成AI特集 ／ 実務・制作・管理 ／ 2026年9月14日確認
生成AIの活用は、画面に回答を表示する段階から、ファイルを開き、コードを直し、コマンドを実行し、結果を確認する段階へ進んでいる。Codex、Claude Code、Google Antigravityなどは、その変化を示す開発環境である。企業の担当者にとって重要なのは、何行のコードが出てくるかより、どこまでの操作を許可してよいかという問題だ。
自動化の範囲が広がるほど、失敗も文章の間違いでは済まなくなる。誤ったファイル変更、外部への送信、不要な課金、本番環境への操作を防ぐには、性能評価と権限設計を同時に進める必要がある。
「回答する」と「操作する」の境界を明確にする
チャットで修正案を受け取るだけなら、実際の変更は人が行う。一方、エージェントにファイルやツールへのアクセスを与えると、提案と実行が一連の流れになる。便利さの源泉はこの接続にあるが、結果を確認する場所を設けなければ、間違いもそのまま次の工程へ進む。
| 段階 | 許可する作業の例 | 確認方法 |
|---|---|---|
| 読む | コード・文書の確認、問題点の整理 | 参照範囲と外部送信先を確認 |
| 変更案を作る | 作業用の複製やブランチで修正、テスト実行 | 差分とテスト結果を人が確認 |
| 外部へ反映する | 公開、メール送信、本番更新、購入 | 対象と内容を提示し、実行前に承認 |
最初の導入では、三段階目を自動化しない方が、問題を切り分けやすい。下書きや変更案を作るところまで任せ、人が確認して反映する。ここで十分な成功記録が得られてから、限定された操作だけを次へ進める。
同じ開発AIでも、作業環境と契約は違う
CodexにはChatGPTの契約で利用する経路と、APIキーを用いる経路がある。Claude Codeは権限モードによって承認の扱いが変わり、手動モードと自動判定を伴うモードでは操作時の挙動が異なる。Antigravityは、GoogleがGemini 3.8 Flashの利用経路として案内するエージェント型の開発環境である。
比較する際は、どのモデルが選べるかだけでなく、ローカルかクラウドか、コードをどこへ送るか、何が利用枠を消費するかを確認する。画面上の操作が簡単でも、組織として管理できなければ、個人の試用から全社導入へは進めない。
承認を減らす前に、触れてよい範囲を狭める
毎回の承認が多いと、利用者は内容を読まずに許可するようになりやすい。そこで承認そのものを外すのではなく、作業ディレクトリ、ネットワークの接続先、利用するアカウント、費用上限を限定する方が管理しやすい。
例えば検証用のリポジトリには本番の認証情報を置かず、外部連携には読み取り専用や期限付きの権限を使う。操作の履歴を残し、途中で止めても変更箇所が分かる状態にする。権限の強い一つのアカウントを全工程で共有する構成は、失敗したときの影響を大きくする。
外部文書の命令を、作業指示に昇格させない
エージェントが読むウェブページや文書、リポジトリには、利用者の指示ではない文章が含まれる。そこに操作を誘導する文言があっても、実行命令として扱わせない設計が必要だ。外部情報を読む経路と、操作を許可する経路を分けることが重要になる。
検証では、業務資料の中に指示に見える文言が含まれている場合や、参照先から別の送信先へ誘導される場合を用意する。処理が正しく停止するか、内容を勝手に実行しないかを確認する。安全対策は、モデルが高性能になったことで不要になるものではない。
完成判定は、エージェント自身の報告から独立させる
「修正できた」という回答と、実際に要件を満たしたことは別である。コードなら既存テストと追加テスト、文書なら数値照合と必須項目、表計算なら元データとの集計差分を使う。確認項目は作業の前に決め、生成後に都合よく変えないことが大切だ。
記事公開の例なら、下書き保存、画像表示、見出し、リンク、公開状態を別々に確認する。メール作成の例なら、本文の品質と、宛先・添付・送信の承認を分ける。エージェントに一括して「完了」を判定させないことで、作業を任せる範囲を広げやすくなる。
エージェントの価値は、放置できる時間では測らない
導入の成果は、人が見ていない時間の長さではなく、確認を含めた全工程の短縮と、失敗時の回復のしやすさで測るべきである。長時間動かして最後に全体をやり直すより、小さな単位で完成を確かめながら進める方が、実務の利益につながる場合がある。
まずは一つの反復作業を対象に、許可範囲、完成条件、費用上限、復旧方法を一枚にまとめる。その設計図があるかどうかが、便利な試用と継続できる運用を分ける。