Fable 5が使えるようになって、最初に俺が考えたのはAIエージェントを大量に作ることだった。
法人営業、商談準備、記事制作、SNS運用、障害対応。
自分がやっている仕事を全部エージェント化すれば、一気に楽になると思った。
でも、実際に設計を進めるうちに気づいた。
エージェントは、作っただけでは運用できない。
動いたのか。失敗したのか。なぜその判断をしたのか。前回より良くなったのか。本番へ出していいのか。問題が起きたときに元へ戻せるのか。
ここまで管理できなければ、エージェントは増えるほど危険になる。
そこで途中から方針を変えた。
俺がFable 5で作るべきなのは、エージェントそのものではない。
エージェントを作り、評価し、改善し、安全に本番へ出すための工場だ。
100個のエージェントを手作業で作るより、100個を同じ品質で作れる工場を1つ作る方が強い。
この記事では、俺が実際にFable 5を使って進めた全業務の棚卸し、自己改善型AI事業OS、Agent Factory、安全な本番昇格、そして実装結果まで公開する。
Fable 5を単発成果物で終わらせるともったいない
Fable 5に記事を書かせる。
資料を作らせる。
コードを1本生成させる。
専用プロンプトを作らせる。
もちろん、それだけでも便利だと思う。
ただ、それではFable 5の能力を一時的に借りているだけだ。
利用条件が変わったり、別モデルへ移行したりした瞬間、その能力の大部分を失う。
俺が今回重視したのは、Fable 5の回答を残すことではない。
Fable 5の考え方を、仕組みとして残すこと。
優秀な記事を1本作ってもらうより、企画、構成、執筆、画像設計、品質確認、入稿、公開後の計測、改善まで回せる仕組みを作った方がいい。
これならFable 5が使えなくなっても、Claude CodeやCodex、別のAIモデルへ引き継げる。
単発の成果物は消費される。
仕組みは次の成果物を生み続ける。
最初にやるべきは全業務の棚卸し
AIエージェントを作る前に、まず自分の業務と資産を全部見せた。
対象はGoogle Drive、スプレッドシート、VPS、Git、cron、systemd、Xtend、Note Publisher、法人営業、X、Threads、LINE、note、WordPress、ココナラ、財務、KPI、作業日記、再現性ログなど。
一つひとつを見ると、それなりに動いている。
でも、全体で見ると問題が出てきた。
- 正本が複数の場所に分散している
- 自動化が停止しても検知できていない
- 法人営業の返信検知が弱い
- フォーム送信がmanual_requiredで止まる
- システムごとにログ形式が違う
- 外部操作前のQA基準が統一されていない
- エージェント品質の合格基準がない
つまり、エージェントを追加する前に、会社そのものの構造を整理する必要があった。
エージェントを作る前に、AIが迷わず働ける会社の構造を作る。
人間でも、担当業務、参照資料、完了条件、報告先が曖昧な会社ではまともに働けない。
AIも同じだ。
曖昧な業務をそのまま自動化すると、曖昧な処理が高速で実行されるだけになる。
業務OSを先に作る
棚卸しの次に必要なのが業務OSだった。
ここでいうOSは、大げさな管理画面ではない。
最低限、次を明確にする。
- どの業務が存在するか
- 何を入力として受け取るか
- どんな処理をするか
- 何が完成条件か
- どこへ保存するか
- 誰が確認するか
- 失敗したらどうするか
- 何をログへ残すか
たとえば法人営業は、メール文を作るだけでは終わらない。
候補企業を探す。対象条件を確認する。重複を除外する。企業情報を調べる。提案文を作る。禁止表現を確認する。メールを送る。結果を記録する。エラーならフォームへ切り替える。返信を検知する。返信内容を分類する。次の行動を決める。
ここまでで1つの業務だ。
この流れを定義せずに営業エージェントを作っても、メール生成機にしかならない。
100個のエージェントよりAgent Factory
最初は個別のエージェントを順番に作る予定だった。
でも、それでは設計品質がばらつく。
あるエージェントにはエラー処理がある。別のエージェントにはない。
あるエージェントにはテストがある。別のエージェントはプロンプトだけ。
ログ形式も、評価方法も、フォルダ構造も違う。
数が増えるほど管理不能になる。
そこで作ったのがAgent Factoryだ。
Agent Factoryは、業務仕様であるspecを入力すると、同じ規格でエージェント設計一式を生成する。
- Agent Charter
- input schema
- output schema
- 判断ルール
- system prompt
- task prompt
- tools設定
- memory policy
- error policy
- evaluation metrics
- テスト
- Sandbox
- README
- Codex実装指示書
俺が欲しかったのは、エージェントの数ではない。
再現可能なエージェント開発能力だ。
使えるエージェントに必要な15項目
実務で使うなら、最低でも次の項目が必要になる。
- 目的
- 対象業務
- 入力
- 出力
- 完了条件
- 判断基準
- 使用ツール
- 参照する正本
- 記憶方針
- 禁止事項
- エラー処理
- ログ
- 評価指標
- テスト
- 本番昇格条件
ここまで揃って初めて、実務で使えるエージェントになる。
プロンプト1本を作って終わりではない。
自己改善は勝手な本番書き換えではない
今回、特に作りたかったのが自己改善ループだった。
ただし、AIが勝手に自分のコードやプロンプトを書き換え、そのまま本番へ反映する構成にはしていない。
自己改善の流れはこうだ。
実行
→ ログ
→ 評価
→ 原因分類
→ 改善案
→ Sandboxテスト
→ 現行版比較
→ 人間承認
→ Canary
→ Production
→ Rollback
AIには改善案と証拠を作らせる。
本番へ昇格させるかは、人間が決める。
たとえば営業メールの返信率が落ちたとしても、AIが勝手に営業文を変更するわけではない。
送信対象、件名、本文、提案内容、送信時間、配信エラーなどを分析し、原因を分類する。改善案をSandboxで試し、現行版と比較し、人間が確認したうえで一部へ適用する。
これが安全な自己改善だ。
実際にFable 5で構築した結果
ここまでの話は構想だけではない。
実際にFable 5を使って、自己改善型エージェントOSのPHASE 1・2まで実装した。
今回の実装差分は次の通り。
- 新規97ファイル
- 5,207行
- テスト72件合格
- 外部送信なし
- 課金処理なし
- Git pushなし
- cron変更なし
- 既存資産の直接変更なし
保存先はsecretary/agent-os/。
完成したZIP全体には、生成物、テスト、ドキュメントなどを含め180ファイルが格納されている。
重要なのは、これだけ実装しても外部送信や本番変更を一度も許可していないことだ。
実装した共通基盤
- 共通イベントログ
- 秘密情報マスク
- エラー分類17種
- 評価エンジン
- 改善提案エンジン
- Prompt Registry
- Skill Registry
- Promotion Gate
- ロールバック
- スマホ向けダッシュボード
- Sandbox
- Agent Factory
単にエージェントを動かすだけではない。
何を実行したかを記録し、結果を評価し、失敗原因を分類し、改善案を作り、現行版と比較し、問題があれば戻せる基盤まで作った。
最初に作った実務エージェント
最初の実務エージェントは3つ。
- 法人営業参謀
- 商談準備
- コンテンツ再利用
法人営業参謀は、営業文を作るだけではない。企業情報、過去履歴、返信内容、次に取るべき行動を整理し、営業判断を支援する。
商談準備は、相手の事業内容、発信、想定課題、質問事項、提案候補を面談前にまとめる。
コンテンツ再利用は、作業ログ、記事、実践結果をX、Threads、ブログ、LINEなどへ展開する。
Agent Factoryが生成できるもの
今回のAgent Factoryは、specを入力すると、Charter、Schema、判断ルール、Prompt、22件のテスト、Sandbox、Codex実装指示書まで一括生成できる。
つまり、エージェントごとにゼロから設計し直す必要がない。
業務仕様を渡せば、同じ規格、同じ安全基準、同じテスト基準で作れる。
俺が最初に考えていたのは、複数のエージェントを作ることだった。
実際に作ったのは、複数のエージェントを同じ品質で生産できる工場だった。
本番へ接続したもの、止めたもの
基盤が完成したからといって、全部をそのまま本番へ接続したわけではない。
現時点で承認したのは次の4つ。
- 返信分類ルール0.2.0のShadow運用
- 実Gmailへの読み取り専用接続
- form_runnerのイベント化
- ダッシュボードのcron定期生成
Shadow運用では既存処理を変更せず、裏側で新しい分類結果だけを記録する。
Gmailも最初は読み取り専用だ。AIはメールを読めても、返信や送信はできない。
一方、次は保留した。
- 実LLM接続
- 自動返信
- フォームの実送信
- 顧客ステータスの本番更新
技術的に接続できるかと、本番へ接続してよいかは別問題だ。
動かせるから動かす、では危ない。
誤送信、顧客情報の更新ミス、想定外の課金、LLM出力の誤り。評価データと運用ルールが揃っていないものは、本番へ昇格させなかった。
コピペで使えるAgent Factory構築プロンプト
以下が、今回の業務棚卸しとAgent Factory設計に使える公開版プロンプトだ。
あなたは、業務改善アーキテクト、AIエージェント設計者、
自動化エンジニア、QA責任者です。
目的は、私の業務を棚卸しし、
高品質なAIエージェントを継続的に作成・評価・改善できる
Agent Factoryを構築することです。
最初に、以下を整理してください。
1. 日次・週次・月次業務
2. 各業務の入力・処理・出力
3. 使用しているツール
4. 人間の判断が必要な箇所
5. AIへ任せられる箇所
6. メール送信、投稿、ファイル変更などの外部操作
7. 認証情報、個人情報、顧客情報などの秘密情報
8. 成功条件
9. 失敗条件
10. 売上増加または作業時間削減への影響
次に、自動化候補を以下の基準で評価し、優先順位を付けてください。
- 事業への影響
- 削減できる作業時間
- 実装難易度
- 失敗時のリスク
- 他業務への再利用性
- 必要な人間判断の量
その後、最優先の業務について、以下を作成してください。
- Agent Charter
- input.schema.json
- output.schema.json
- system prompt
- task prompt
- tools.yaml
- memory policy
- error policy
- evaluation metrics
- 最低20件のテストケース
- dry-run設計
- Sandbox設計
- Promotion Gate
- Rollback手順
- Codex用実装指示書
AIが本番環境を無承認で変更する構成は禁止です。
外部送信、SNSやWebサイトへの公開、課金、認証情報の使用や変更、Git push、cron、systemd、Google Drive変更、本番データ更新は、必ず人間承認を必要としてください。
自己改善は、必ず以下の順番で実行してください。
実行
→ ログ
→ 評価
→ 原因分類
→ 改善案
→ Sandboxテスト
→ 現行版との比較
→ 人間承認
→ Canary
→ Production
→ 問題発生時はRollback
改善案は、現行版より良いことを示す証拠がない限り、本番へ昇格させないでください。
最後に、すべての作業を以下の3つへ分けて報告してください。
1. 実装済み
2. 設計のみ完了
3. 人間確認待ち
各項目には、次に実行すべき具体的な作業も記載してください。
Fable 5終了後にも残るものを作る
Fable 5がどれだけ強くても、特定モデルへ依存しすぎるのは危険だ。
だから成果物は、モデルではなく構造として残す。
- Markdown
- JSON Schema
- YAML
- Python
- テスト
- Git
- 共通ログ
- 評価データ
- 実装指示書
この形式なら、Claude CodeでもCodexでも扱える。
Fable 5には全体設計、矛盾の発見、業務分解、評価基準作成を任せる。
実装はCodexやClaude Codeへ引き継ぐ。
日常運用は、費用の安いモデルやルールベース処理へ落とす。
強いモデルは、強いモデルにしかできない設計へ使う。
まとめ
Fable 5が使える間に、エージェントを何個作れるか競う必要はない。
重要なのは、Fable 5が使えなくなった後も残るものを作ることだ。
記事を100本作らせるより、記事を作り続けられる仕組みを作る。
エージェントを100個作るより、100個を同じ品質で作れる工場を作る。
自動化を増やすより、実行結果を評価し、安全に改善できるOSを作る。
Fable 5の能力を借りるだけでは弱い。
その能力を、自分の事業資産へ変える。
俺が作っているのはAIエージェントではない。
実行し、記録し、評価し、人間の承認を通しながら少しずつ強くなっていくAI事業OSだ。
今しか借りられないかもしれない思考力を使って、今後も使い続けられる工場を作る。
それが、今やるべき一番強い使い方だ。
