目的・判断・責任
何を改善したいか、何を正しいとするか、 公開してよいかなど、仕事の意味と最終判断を担当します。
いつ使う知識？
AIエージェントやCodexなどに複数工程の仕事を任せる前、 定型作業をAIで自動化しようとするとき、 「どこまでAIにやらせるべきか」が曖昧になったときに使います。 メールやクラウドなど外部サービスへ接続するときだけでなく、 ローカルのファイル操作や開発作業でも同じ考え方を使えます。
境界設計は「AIに何を禁止するか」だけではない
AIエージェントの安全性というと、 「削除を許可しない」「外部送信には承認を入れる」といった 権限制御が最初に思い浮かびます。 もちろん重要ですが、それだけでは十分ではありません。
その前に考えたいのは、 仕事そのものをどこで分けるかです。
AIエージェントの境界設計とは、
AIをどこまで許可するかだけではない。
仕事を、人が判断する部分、AIが考える部分、
プログラムが確実に処理する部分へ分けることである。
AIにできる処理でも、AIに任せることが合理的とは限りません。
曖昧さを含む思考
調査、要約、分類、設計案、文章作成、コード作成など、 入力によって答えが変わる処理を担当します。
決まった処理
日付、形式チェック、ファイル生成、変換、集計など、 ルールが決まっている処理を確実に実行します。
まず「本当にAIが必要か」を考える
AIが使えるからといって、 すべての工程をAIへ渡す必要はありません。 判断基準が固定できる処理は、 通常のプログラムの方が速く、安く、再現しやすい場合があります。
| 仕事の性質 | 向いている担当 | 例 |
|---|---|---|
| 目的や優先順位を決める | 人 | 何を自動化するか、品質をどこまで求めるか、 公開してよいかを判断する。 |
| 答えをルールだけで決めにくい | AI | ニュース選定、文章の要約、設計案、 コードレビュー、問い合わせの分類。 |
| 入力と処理結果が一意に決まる | 通常プログラム | 日付計算、JSON検証、HTML生成、 ファイル名チェック、index更新。 |
| 失敗時の影響が大きい | 人＋仕組み | 公開、外部送信、削除、購入、 本番環境への反映。 |
実例：Learning ShareのDaily生成はどう分けているか
Learning ShareのDaily記事生成も、 「記事を作って公開準備まで全部AIに任せる」 という構成にはしていません。
AIが必要な部分と、通常プログラムで確実に処理できる部分を 分離しています。
プログラム
1. 対象日と作業条件を準備する
PowerShellが対象日や出力先を決め、 AIが勝手に日付やファイル名を変更しないようにします。
AI
2. ニュースを調査し、記事内容を作る
AIは Skills/explain-it-ai-news/SKILL.md と
タスク定義を読み、ニュースを調査して
構造化JSONを作成します。
プログラム
3. JSONを検証する
必須項目や形式をPowerShellで確認します。 「AIが正しいと言ったから正しい」とは扱いません。
プログラム
4. HTMLを生成する
AIに自由なHTMLを書かせず、 検証済みJSONから決められたテンプレートでHTMLを生成します。
プログラム
5. indexを更新し、最終検証する
記事の日付、ファイル名、HTML、 トップページへの登録をスクリプトで確認します。
人
6. Git操作・公開判断を行う
SkillではGit操作を禁止しています。 AIが記事を生成できることと、 リポジトリへ反映してよいことを分けています。
この構成では、AIが担当するのは 「何を記事にするか」「どう説明するか」 という曖昧な部分です。 一方で、日付や形式、HTML生成、index更新のような 決まった処理はPowerShellへ寄せています。
AIを自動化の中心に置くのではなく、
AIが必要な場所だけを自動化の中へ差し込む。
AIへ渡す仕事も、必要なら工程を分ける
AIに任せる部分の中でも、 一つのエージェントへ最初から最後まで任せる必要はありません。
特に設計や開発のような複雑な作業では、 「考える役割」と「実行する役割」を分けることで、 最初の思い込みを最後まで引きずる問題を減らせます。
- 人が目的を決める 何を作るか、守る条件、完了条件を決める。
- 設計する AIに構成、論点、実装方針、必要な作業を整理させる。
- 実行する 設計結果を入力として、別工程で実装や生成を行う。
- 検証する テストやルール、人の確認で成果物を評価する。
すべての作業で分離する必要はありません。 小さな文章修正なら一つの会話で十分です。 影響範囲が大きいほど、工程を分ける意味が大きくなります。
コンテキストにも境界を作る
AIへ多くの情報を渡せば、 必ず精度が上がるわけではありません。 関係のない資料や古いルールが増えるほど、 どの情報を優先するかが曖昧になります。
必要な情報だけ渡す
リポジトリ全体ではなく、 作業対象、ルール、関連ファイルを絞ります。
変更してよい範囲を分ける
「読んでよい」と 「編集してよい」を同じ意味にしません。
役割ごとに情報を変える
設計AI、実装AI、レビューAIが 同じコンテキストを持つ必要はありません。
古い情報を残さない
仕様やルールを更新したら、 以前の指示が同時に参照されないよう整理します。
コンテキストを小さくすることは、 トークン消費を減らすだけでなく、 AIの判断範囲を限定する境界にもなります。
ツールが使えることと、使ってよいことを分ける
AIがファイル、ブラウザ、メール、クラウド、 Gitなどのツールを利用できる場合でも、 すべての操作を同じ権限で許可する必要はありません。
| 操作 | 初期の境界 | 確認したいこと |
|---|---|---|
| 閲覧・検索 | 対象を限定して許可 | 読んでよいデータ、機密情報、 外部サイトから受ける指示。 |
| ファイル生成 | 専用の出力先へ許可 | 既存ファイルを上書きしないか、 出力形式を検証できるか。 |
| 既存データ更新 | 対象を限定し差分確認 | 変更前後、件数、戻し方、 他の処理への影響。 |
| 削除 | 原則として人が承認 | 復旧可能か、対象が正しいか、 バックアップがあるか。 |
| 外部送信・公開 | 実行直前に人が確認 | 宛先、内容、公開範囲、 個人情報や機密情報。 |
| Git・本番反映 | 段階的に許可 | 差分、ブランチ、テスト結果、 ロールバック方法。 |
「この内容でよい」と確認することと、 「外部へ送ってよい」「本番へ反映してよい」 と承認することも別の判断です。
停止条件は、プロンプトではなく仕組みにする
「分からなければ止まってください」と書くだけでは、 停止条件として弱い場合があります。 可能なものは実行側でも制限します。
回数
同じ処理の再試行回数に上限を置き、 無限ループを防ぎます。
時間
実行時間やタイムアウトを決め、 終わらない処理を停止します。
費用
API利用量や月額の上限を置き、 想定外の消費を防ぎます。
対象
許可していないファイル、 データ、サービスへ触れたら停止します。
入力不足
必須情報がない場合に、 AIが推測だけで処理を続けないようにします。
検証失敗
JSON、テスト、スキーマなどの検証を通らなければ 次工程へ進ませません。
完了条件は、AI自身の「できました」にしない
AIが「完了しました」と返しても、 本当に仕事が終わったとは限りません。 完了条件は、AIの自己申告とは別に用意します。
| 成果物 | 確認方法の例 |
|---|---|
| コード | ビルド、テスト、静的解析、 変更差分、実際の動作確認。 |
| JSON・CSV | スキーマ検証、必須項目、 型、件数、文字コード。 |
| HTML | 必須要素、リンク、 表示確認、既存ページとの整合。 |
| 調査結果 | 一次情報、日付、 対象地域、提供条件、出典。 |
| 設計・提案 | 要件との対応、 前提条件、リスク、未決事項。 |
自動検証できるものはプログラムへ任せ、 意味や妥当性の判断が必要な部分だけを人が確認すると、 レビュー負荷も抑えやすくなります。
最初から完全自動化を目指さない
自動化の範囲は、 実際の失敗を見ながら少しずつ広げます。
- AIに作らせる 人が毎回確認し、 どんな失敗をするか把握する。
- 検証を固定化する 繰り返し確認している項目を スクリプトやテストへ移す。
- 安全な工程だけ自動化する 実績を確認してから、 次の工程への自動実行を許可する。
この繰り返しで、 人が毎回やっていた確認の一部が プログラムへ移っていきます。
重要なのは 「人の確認をなくすこと」そのものを目的にしないこと です。 必要な判断だけを人に残し、 機械的に確認できる仕事を減らしていきます。
境界は、使いながら動かしてよい
最初に決めた境界が、 ずっと正しいとは限りません。
AIが安定して処理できることが分かれば、 人が確認していた工程を自動検証へ移せます。 逆に、失敗が多い工程では権限を狭めたり、 AIから通常プログラムへ処理を戻したりします。
AI → プログラム
出力ルールが固まった処理は スクリプトやテンプレートへ移します。
人 → 自動検証
毎回同じ確認をしているなら、 テストやバリデーションへ移します。
自動 → 人
失敗の影響が想定より大きければ、 承認点を戻します。
AI → 人
判断基準が定まらない仕事は、 無理に自動化せず人へ戻します。
境界設計は、 AIを閉じ込めるためだけのものではありません。 安全に任せられる範囲を明確にして、 任せられる仕事を増やしていくための設計 でもあります。
AIへ仕事を任せる前のチェックリスト
- 仕事を、人・AI・通常プログラムの役割へ分けた
- AIを使わなくてもよい定型処理を切り出した
- AIが参照してよい情報と変更してよい範囲を分けた
- 閲覧・更新・削除・送信・公開の権限を分けた
- AI自身の自己申告とは別に完了条件を決めた
- 自動検証できる項目をスクリプトやテストへ移した
- 再試行回数、時間、費用、対象外アクセスの停止条件を決めた
- 外部送信・公開・削除など、戻しにくい操作の承認点を置いた
- 複雑な作業では、設計・実行・検証を分ける必要がないか確認した
- 実際の失敗を見て境界を見直す方法を決めた
フル自動化の最終形
この考え方を十分に検証し、手順や許容範囲を固定できた業務では、通常時に人が一件ずつ確認しなくても完了する構成を目指せます。 ただし、フル自動化は「AIに全部任せること」ではありません。 人が目的・ルール・許容範囲を決め、通常プログラムが入力や対象、実行条件を管理し、判断が必要な部分だけをAIに任せます。 そのうえで検証と停止条件を組み合わせることで、正常系を自動で進めます。
人
目的・ルール・許容範囲を決める
何を達成するか、対象や権限、費用、時間の上限、公開してよい条件を事前に定義します。
通常プログラム
入力・対象・実行条件を管理する
決められた範囲のデータを受け取り、処理対象や実行回数、時間、権限を制御します。
AI
判断が必要な部分だけを処理する
分類や要約など、ルールだけでは決めにくい部分を担当します。定型処理は通常プログラムに任せます。
自動検証
スキーマ・テスト・ルールで結果を確かめる
形式や必須項目、内容、変更範囲などを検証し、合格した場合だけ次へ進めます。
自動実行
問題がなければ次工程へ進み、条件内で公開・反映する
事前に定義した条件を満たす範囲で後続処理も自動実行し、ログを残して完了します。
フル自動化の最終形は、正常系は人を通さず完了し、例外だけ人へ戻す状態です。 「人が不要」になるのではなく、人の確認を例外対応やルールの見直しに集中させます。
自動処理を止めて人へ戻す条件
次のような場合は処理を続けず、変更や公開の前に停止して人へエスカレーションします。
情報・判断の不足
必須情報が不足している、またはAIの判断に十分な確信がない。
検証・再試行の失敗
自動検証に失敗した、または同じ処理が規定回数以上失敗した。
許可範囲の超過
対象・権限・費用・時間の上限を超えた。
想定外・取り消せない操作
想定していない例外が起きた、または事前ルールだけでは安全性を保証できない不可逆な操作がある。
確認を減らす順序
- 人が毎回確認するまず実際の結果と失敗の傾向を把握します。
- 確認項目を自動検証へ移す繰り返し確認する形式やルールをテストにします。
- 正常系を自動実行する検証に合格した処理だけ次工程へ進めます。
- 実績のある範囲で承認を省略する十分な実績ができた対象・条件に限って適用します。
- 例外時だけ人へ戻す停止条件に当たった場合は処理を止め、確認を依頼します。