| 領域 | 具体例 | なぜ向くか |
|---|---|---|
| 大量の反復・並列調査 | 複数ファイル・複数候補を同時に調べて突き合わせる | 人間が一つずつ見るより速く、疲れによる見落としもない |
| 定型パイプラインの組み立て | 「情報収集→加工→通知」のようなグルーコードの実装 | コード自体は決定的だが、組み立て作業は反復的で自動化に向く |
| 一次調査・下調べ | 原因不明のエラーのログ調査、複数箇所の突合、設定ファイルの整合性チェック | 人間が見落としがちな地道な突合を苦にしない |
| 選択肢の整理・トリアージ | 「深刻度×影響範囲÷コスト」のような多軸評価で優先順位の叩き台を作る | 一貫した基準で機械的に並べ替えられる（最終判断は人間） |
| 雑多な情報の構造化 | 会話ログや調査結果を、見出し・表・図のあるドキュメントに変換する | 定型的な変換作業であり、人間がやると時間がかかる |
| 第二の目（レビュー） | コード変更やドキュメントの見落とし・矛盾の指摘 | 書いた本人が気づきにくい視点を機械的に補える |
| 分業のオーケストレーション | 「監督AIが方針を決め、複数の実行AIに専門作業を振る」構成 | 役割ごとにコンテキストを分離でき、1つのセッションが肥大化しない |
| 領域 | 何が起きうるか | 対策 |
|---|---|---|
| 完全自律・無人実行の無条件信頼 | ツールが主張する「サンドボックスで隔離」を鵜呑みにすると、実際には想定より広い範囲を読み書きしていることがある | 機微な用途に使う前に、隔離された検証環境で実際の読み書き範囲を確認してから本番投入する |
| 秘密情報の受け渡し窓口にすること | APIキー等をチャットに貼らせる/AIに直接読ませると、会話ログや出力に残るリスクがある | 秘密情報の設置はユーザー自身が完結させる手順を使い、AI側は「存在確認・権限確認」までに留める |
| 決定的でなければならない処理をLLMに任せる | 金額集計・パースのような「一意の正解がある」処理をLLMにやらせると、再現性のないブレが生じうる | パース・集計は決定的なコードで行い、LLMは分析・要約・異常検知など非決定的でよい領域に限定する |
| 別セッション・別AIの調査結果を無検証で信じる | 引き継ぎメモは、作成時点から状況が変わっている、あるいは調査自体に誤りがあることがある（行番号のズレ、既に直っている問題を「未修正」と誤記、等） | 公開操作（外部への登録・通知・コミット等）の前に、現行の状態で必ず再検証する |
| 権限境界の「迂回経路」 | 「直接の読み取りは禁止」しても、汎用コマンド経由なら通ってしまう、といった抜け道が実際に見つかることがある | 迂回経路を定期的に洗い出す。ルールは「何を禁止するか」だけでなく「その禁止をどう迂回されうるか」まで検討する |
| ツールによって権限モデルの粒度が全く違う | 細かいファイル単位の許可/禁止/要確認を持つツールもあれば、「読み取り専用/書き込み可/フルアクセス」の大枠3段階しか持たないツールもある | 導入前にそのツールの権限モデルの粒度を確認し、粒度が粗いツールには重要な操作を任せすぎない |
導入前に完璧に理解する必要はないが、以下は最低限押さえておくと事故を防げる。
一つのAIに全部やらせず、「方針を決めてレビューする層」と「専門作業を実行する層」を分けると、コンテキストが汚れず、コストも下げやすい。
図: 監督AIが調査・実装を専門の実行者に振り、圧縮した要約だけを受け取って人に報告する構成。実行者の生の出力を監督AIのコンテキストに持ち込まないのがポイント。
反復的な情報収集・加工・通知は、スケジューラ（cron/launchd等）とAIを組み合わせて無人化すると効果が大きい。
一度作り込んだ自動化・権限設定も、放置すると陳腐化する（無効化したはずの自動実行が別経路で二重に動いていた、権限ルールに迂回経路があった、等）。四半期に一度程度、以下を確認する運用にすると事故を未然に防げる。
同じツールでも、使う人に合わせて育てると体感の生産性が大きく変わる。
固有名詞・具体的な製品名は伏せ、パターンとして一般化したもの。
| 出来事（一般化） | 教訓 | 今の運用 |
|---|---|---|
| フルエージェント型のCLIツールを「厳格なサンドボックス」フラグ付きで試したところ、隔離検証で実際にはローカルの設定ファイル群を広範囲に読み込んでいたことが判明した | ツールの安全機構の「主張」と「実態」は別。事前検証なしに機微な用途へ投入しない | 新規導入時は、まず隔離された空環境で実際の読み書き範囲を検証してから本番投入する |
| 別セッション（特に人が介在せず遠隔で動いたセッション）が残した調査結果を、そのまま公開操作に使おうとしたら、行番号のズレと事実誤認が見つかった | 引き継ぎメモは作成時点のスナップショットに過ぎず、時間経過や調査自体の誤りで陳腐化する | 公開操作の前には、記載内容を現行の状態で必ず再検証してから実行する |
| ある自動実行の仕組みが有効かどうか確認せずに、それを前提に対応方針を質問してしまい、実際には既に無効化されていたということがあった | 確認可能な事実は、質問する前に自分の手で検証すべき | 設定の有効/無効・値・稼働状態はコマンド等で確認してから話題にする。推測ベースで選択肢を並べない |
| 権限ルールで「特定の直接操作」を禁止していたが、汎用コマンド経由で同じ結果に到達できる迂回経路が複数見つかった | 「何を禁止するか」だけでなく「その禁止がどう迂回されうるか」まで検討しないと、ルールは形骸化する | 権限ルールを追加・変更する際は、迂回経路の洗い出しをセットで行う |
| 見た目上は正しく見えるコード変更を、実際にレンダリング・実行して確認せずに「動くはず」と判断し、不具合を連続で見逃した | コードを読んで「動くはず」と判断するのと、実際に動かして確認するのは別物 | 出力物・UI変更は、必ず実機で見た目・挙動を確認してから完了とする |
| 借用・共有アカウントベースの安価なリソースを常時稼働の主力として使っていたら、提供元都合で突然使えなくなった | 恒久利用したい重要な役割には、安定した契約ベースのリソースを充てるべき | 常時稼働・重要な役割には正規契約のリソースを割り当て、借用リソースは補助的な用途に限定する |