SESエンジニアとして客先常駐をしていると、「自分がいなくなったら、この仕事の判断は誰がするんだろう」と思ったことがある人は多いはずだ。私は今、経営の意思決定補助・財務管理・タスク管理・マーケティング分析までを、Claude Code上に構築した9体のAIエージェントに任せている。今日は2026年10月13日時点で実際に運用している「経営OS」の設定ファイルやコマンドをそのまま出しながら、技術面と経営面の両方を書く。
架空の成功談を書くつもりはない。むしろ「まだ検証できていない部分」も含めて、実際に手元で動いているものだけを紹介する。
なぜ経営をAIエージェントに分担させたか
一人で経営をしていると、財務（CFO視点）・技術（CTO視点）・運営（COO視点）・マーケティング（CMO視点）・全体統括（CEO視点）を同時に持ち続けるのが難しい。NotionやExcelで管理しようとしても、「今日はどの数字を見るべきか」を思い出すコスト自体がボトルネックになる。1人で経営から実装まで担うなら、年収やSESの単価の話以前に、まず「見るべき場所を自分の代わりに巡回してくれる仕組み」が必要だと感じた。
そこでClaude Codeのサブエージェント機構を使い、役職ごとに専用のエージェントを定義した。Claude Codeのサブエージェントは.claude/agents/*.mdにYAMLフロントマター付きのMarkdownを置くだけで定義できる。例えばCFO役のエージェントは、簡略化するとこういう形になる。
name: cfo
description: CFO（最高財務責任者）。freee連携で財務データ取得・PL生成・仕訳計上・未決済管理・キャッシュフロー予測を実行
tools: Bash, Read, Edit
descriptionに役割と担当業務を書いておくと、メインのClaude Codeが「今回はCFOの仕事だ」と判断して自動的に委譲してくれる。経営者が自分で「このタスクはどのエージェントに投げるべきか」を毎回判断しなくていいのが、この仕組みの一番楽な部分だ。
実際の9エージェント構成
現在運用している9体の役割分担は次の通り。
| 役職 | 主な担当 |
|---|---|
| CEO | CFO/CTO/COO/CMOの報告を統合し経営ダッシュボードと意思決定支援 |
| CFO | freee連携で財務データ取得・PL生成・仕訳計上・未決済管理・キャッシュフロー予測 |
| CTO | 複数プロダクトのヘルスチェック・技術スタック管理・開発優先度の提案 |
| COO | タスク進捗・クライアント管理・営業パイプライン・運営状況の横断管理 |
| CMO | GA4/Google Ads/GSCデータを統合したマーケティング戦略提案 |
| cc-secretary | inbox/today/archiveのYAML操作による秘書業務 |
| cc-knowledge | 教訓・パターン・インシデントの記録と検索 |
| cc-company | 全社横断の情報整理・取りまとめ |
| cc-products | プロダクト別の状況管理 |
毎日見る項目はさらにショートカット化している。入力すると内部で対応するコマンドが呼ばれる仕組みで、ダッシュボード確認、財務の未決済確認、タスク確認、プロダクトのヘルスチェック、inboxの一覧表示などを、それぞれ短い一語のコマンドで呼び出せるようにしている。地味だが、毎朝の巡回を1タイプずつで済ませられるのは積み重なると大きい。
モデルの割り当ても役職で分けている。CEOのように複数の報告を統合して意思決定材料を作る役割には、推論の深さが必要なモデルを割り当て、cc-secretaryのinbox仕分けのような定型処理には、軽量なモデルで十分なことが多い。全エージェントに同じ重いモデルを使う必要はなく、役割の重さに応じてコストと速度のバランスを取っている。
セキュリティ：エージェントに何を触らせるかが一番の設計判断
Qiitaでは直近14日でセキュリティタグの記事が多数ストックされていて、「AIエージェントにAPIキーを渡しても大丈夫か？」という投稿が話題になっている。マルチエージェント構成を実際に組むと、この問題は避けて通れない。
Claude Codeのサブエージェントは、先のtools:フロントマターでツールを個別に絞れる。経営OSでも全エージェントにBashやEditを渡しているわけではなく、役割ごとに最小権限にしている。
- トレンド調査担当のエージェントには
WebSearch, WebFetch, Readだけを渡し、ファイル書き込みやシェル実行は持たせない - デプロイ前検証担当には
Bash, Read, Grepのみを渡し、Edit（書き込み）は持たせない。検証担当がコードを直接書き換えられたら、検証そのものの意味がなくなる - サイト監査担当には
Bash, Read, Grep, WebFetchを渡すが、外部発信系のツールは渡さない
これは人間の組織でいう「経理担当がシステム管理者権限を持たない」のような権限分離とほぼ同じ発想だ。AIエージェントだから例外にする理由はない。むしろ自律的に動く分、権限の絞り方は人間よりも厳密にすべきだと感じている。SNS投稿を自動化するエージェントについても、生成は下書きまでで公開は必ず人間が承認する、同一アカウントへの連投間隔を強制する、といったルールを明文化している。便利だから全部自動化するのではなく、事故が起きた後に設計し直すのではなく先にガードレールを敷くという考え方だ。
ナレッジ管理と検索：vec1拡張という選択肢
9エージェントのうちcc-knowledgeは、教訓・パターン・インシデントを記録・検索する役割を持つ。現状はYAML/Markdownベースの構造化データをキーワードで検索する作りだが、記録が増えるほど「表現は違うが似ている過去の失敗」をキーワード一致以外の方法で引っ張ってこれるようにしたい、という課題が出てくる。
ちょうどZennの日次トレンドで「SQLite本体にベクトル検索拡張vec1がやってきた」という記事が話題になっていた。SQLiteは個人開発や小規模なエージェント基盤で使うには軽量で扱いやすく、そこにベクトル検索（埋め込みベースの類似検索）が標準的に使えるようになるなら、cc-knowledgeのような「構造化ログ＋類似検索」の用途には相性が良さそうだ。今はこの構成への移行を検討している段階で、まだ本番には入れていない。検討中のものを「導入済み」と書くのは誠実ではないので、ここは正直に書いておく。
ダッシュボードのUIで気をつけていること
経営ダッシュボードは基本的に自分しか見ないとはいえ、見づらいUIは結局使われなくなる。Zennで「嫌われるデザインの歴史」という記事がトレンドに上がっていたが、内輪向けの管理画面でも同じ話が当てはまる。情報を詰め込みすぎた表、強調色を乱用したアラート、クリック数が多い導線は、人間が最後には見なくなる。
CEOエージェントのダッシュボード出力は、「数値→判断材料→次のアクション」の順に並べるだけのシンプルな構成にしている。見た目のかっこよさより、「毎朝1分で読めるか」を優先した。ツールを増やすほど出力は豪華になりがちだが、結局読まれない画面を作っても意味がない。
オーケストレーションの実装：単発タスクとWorkflowの使い分け
9エージェントは常に並列で動かしているわけではない。単発の調査や確認は1体のサブエージェントに投げるだけで十分だが、複数の視点を横断してレビューするような作業は、決定論的なスクリプトで制御したい場面がある。Claude Codeにはこの両方の層がある。
単発タスクはAgentツールでサブエージェントを1体呼ぶだけで済む。「CTOに複数プロダクトのヘルスチェックをさせる」程度ならこれで十分だ。多段階・並列が必要なタスクは、Workflowツールでスクリプトを書き、並列実行やパイプライン処理でエージェントをオーケストレーションする。例えば複数プロダクトの監査を並列で走らせ、結果をCTOエージェントが統合する、という構成だ。
経営の最終判断そのものはAIに渡していない。各エージェントが出すのは「報告」と「選択肢の提示」までで、最終判断は人間（自分）が行う。これは設計として意図的にそうしている。財務の仕訳計上や未決済管理のような定型処理はCFOエージェントに任せているが、「どの契約を切るか」のような判断は自分で決めている。
よくある疑問：経営判断までAIに乗せて大丈夫なのか
この構成を話すと、「契約や人事のような重い判断までAIに任せて大丈夫なのか」と聞かれることがある。答えは「任せていない」だ。エージェントが自律的に実行するのは、freeeへの仕訳登録のような定型作業や、複数データソースを集計してレポートにする作業までで、金額の大きい意思決定や契約の締結・解約には必ず人間の承認を挟んでいる。自律度を上げるほど楽になるのは事実だが、楽さとリスクの許容度は役割ごとに別々に決めるべきだと考えている。経営OSという言葉を使うと全自動の自動運転を想像されがちだが、実態は「巡回と一次整理を代行してもらい、最終判断は自分がする」という、人間の秘書チーム的な設計に近い。
正直なところ：まだ検証中の部分
ここまで技術的な構成を書いたが、経営指標への寄与度を定量的に示せる段階ではない。導入してからの運用期間がまだ短く、「実装が完了している」ことと「効果が出て稼働が安定している」ことはイコールではない、と自分に戒めている。
言えるのは、毎朝の巡回作業（財務チェック・タスク確認・プロダクトヘルスチェック）が、数回のコマンド入力で終わるようになったという、作業プロセス上の変化だ。収益へのインパクトを主張するには、もう少し運用期間を積んでからの方が誠実だと考えている。AIを経営に組み込む話は、どうしても大きな成果を即座に語りたくなるが、再現できない数字を書くよりは、プロセスの変化だけを正直に書く方が、後から読んだときに役に立つと思っている。
SESエンジニアとこの技術の接点
ここまでの話はSESエンジニアには縁遠く見えるかもしれない。客先常駐で特定システムの開発・保守だけを担当していると、こうした「社内ツールを役割分担で設計する」経験そのものに触れる機会が少ないのも、SESエンジニアの実態としてよくある構造だ。要件定義や権限設計の意思決定には関与せず、与えられた仕様の実装に専念するフェーズが長くなりやすい。
これは個々のエンジニアの能力の問題ではなく、多重下請け構造の中で裁量が上流に偏りやすいという業界構造の話だ。だからこそ、独立やフリーランス、あるいは自社開発企業への転職を考えるタイミングで、「AIエージェントに何をどこまで任せるか」「権限をどう設計するか」を自分で決めた経験があるかどうかは、年収やキャリアの選択肢の幅に地味に関わってくる。エンジニアのキャリアガイドとしてよく語られる「コードが書ける」に加えて、「仕組み全体の設計・権限分離を自分の裁量で決められる」経験を、担当案件の外で積んでおく価値はある。
保存版チェックリスト：AIエージェントで経営OSを作るときに確認すること
| チェック項目 | 確認内容 |
|---|---|
| 権限分離 | 各エージェントのtoolsを役割に応じて最小権限にしているか |
| 報告と判断の分離 | エージェントの出力は報告・選択肢の提示までで、最終決定は人間が行っているか |
| 稼働実績の過大表現 | 「実装完了」を「稼働中・効果あり」と言い換えていないか |
| 公開物の人間承認 | SNS投稿など外部に出るものは生成は下書きまでで公開は人間が承認しているか |
| ショートカット化 | 毎日見る項目を1コマンドで呼べる導線を作っているか |
| ナレッジの検索性 | 記録が増えたときにキーワード一致以外で検索できる手段を検討しているか |
| UIの読みやすさ | ダッシュボードが毎朝1分で読めるかを基準に設計されているか |
このチェックリストは、個人開発でAIエージェントを使った業務自動化を試す人にも、SESから独立して自社ツールを作りたいエンジニアにも、そのまま使えるはずだ。保存しておいて、自分の環境で一つずつ潰していくといい。
関連記事
- フリーランスエンジニア年収データ比較2026｜地方リモート単価とSES契約の注意点
- 【2026年最新】AIコーディングツール5選比較|Claude Code・Copilot・Cursorの使い分け
- SES多重下請け構造を規模別に解剖:独立準備とAI活用の完全ロードマップ
AI駆動塾 — AIを使ったスモビジの作り方を学ぶ
Claude Code、OpenClaw、AI経営OSの実践ノウハウを毎週公開中。
月額¥4,980で過去記事すべて読み放題。
書いた人: 合同会社Radineer（フリーランス向け案件サイト FreelanceDB を運営）