【定点観測ログ①】一人社長＋AI社員4人で、会社の意思決定フローを実装してみた ― 起票→計画→稟議→承認→実装を回した検証記録

定点観測ログ①

観測対象： 自社AIエージェント運用体制（Claude Code＋秘書／PM／経理／開発課の4体構成）

観測日： 2026年7月24日時点

前回ログからの変化： なし（本記事がシリーズの起点）

次回観測時に見る視点： ①稼働案件数の推移　②社内ルールの改定有無　③品質チェックでの差し戻し件数の推移

本記事は、この時点で実際に構築・運用した内容の記録です。ツールやルールは今後更新される可能性があり、本記事はあくまで「その時点の実体験」として読んでください。

リード

本記事はブログ「AI進化アーカイブ」の定点観測ログ第1回です。観測対象は、AIそのものの進化ではなく、その進化を実際に取り込んで動かしている「自社のAIエージェント運用体制」であり、今後のログはこの回を起点として前回比較を積み重ねていきます。

会社を一人で立ち上げると、「社長」「経理」「現場」を全部自分一人でこなすことになります。判断のたびに立場を切り替え、承認する側とされる側を自分の中で往復する ── これは地味に消耗します。

そこで今回、Claude Code（Anthropicのコーディングエージェント）を使って、「人間の従業員」ではなく「AI社員」を4人実装してみました。秘書・プロジェクトマネージャー（PM）・経理・開発課という 4つの役割を、それぞれ独立した人格・権限を持つエージェントとして定義し、社内ルールを 1本のルール文書にまとめて全員に守らせる、という構成です。

本記事は、その設計そのものと、実際に1件の案件（今まさにこのブログ立ち上げ案件そのもの）を「社長指示 → 起票 → 計画 → 稟議 → 承認依頼 → 実装」という流れで動かしてみた一次情報の記録です。架空の実験ではなく、この記事自体がその実装フローの成果物の一つになっています。

見出し構成

なぜ「AIに社則を持たせる」ことを試したか
社内ルールに書いたこと ― 投資基準と委任マトリクス
4人のAI社員の役割分担
2フェーズの意思決定フロー
実例：このブログ立ち上げ案件で何が起きたか
わかったこと・まだわからないこと
まとめと今後の検証予定

1. なぜ「AIに社則を持たせる」ことを試したか

一人で会社を回すとき、AIエージェントに作業を任せること自体はもう珍しくありません。自分が今回気になっていたのは一段階先で、「任せた作業の“判断の質”をどう担保するか」でした。

AIエージェントは指示すれば動きますが、指示が曖昧だったり、都度その場のノリで判断基準が変わったりすると、一貫性のない成果物が積み上がっていきます。特に金銭が絡む判断（いくらまでなら使っていいか）や、対外的な行為（公開してよいか）は、「毎回聞く」か「毎回好きにやらせる」かの二択になりがちです。

そこで試したのが、判断基準そのものを1本のルール文書（社則）として先に固定し、役割ごとに権限を分けたAIエージェントに、そのルールの範囲内でだけ動いてもらうというやり方です。人間の会社が就業規則や決裁権限規程を持つのと同じ発想を、AIエージェントの構成に持ち込んでいます。

2. 社内ルールに書いたこと ― 投資基準と委任マトリクス

社則は社内のルール文書として1つにまとめています。ポイントは大きく2つです。

投資の判断基準を数字で先に固定したこと。 1案件あたりの初期投資、月間の新規投資合計、継続課金の追加それぞれについて、小さめの上限額を先に数字で固定しておき、これを超える場合は「稟議書に上限超過と明記し、超過理由と回収見込みを添えて社長の事前承認を得ること」というルールにしました。数字を先に決めておくと、AI社員（経理役）が「この金額は基準内か外か」を毎回自分で判断できるようになります。

何を任せ、何に承認が要るかを3段階に分けたこと（委任マトリクス）。 社内の作業を「即委任」（報告不要）・「事後報告」・「事前承認」の3分類に分け、可逆な行為（後から取り消せる作業）は任せ、不可逆な行為（お金が動く、対外的に公開される等）は承認制にする、という原則で線引きしました。迷ったときは事前承認扱いにする、というルールも合わせて決めています。

これによって、AIエージェントに「自分で先に進めてよい範囲」と「必ず立ち止まる範囲」が明示され、勝手にブログを公開してしまう、勝手に有料サービスを契約してしまう、といった事故を構造的に防ぐ設計にしています（少なくとも設計上はそうなっている、という段階です。長期運用での実効性は後述のとおり未検証です）。

3. 4人のAI社員の役割分担

社則の上に、4つの役割定義ファイルを置き、それぞれ別人格のAIエージェントとして動かしています。

秘書：社長の指示を受けて指示書を起票し、案件フォルダを作成し、各部門に振り分ける。社長への報告は「結論→要判断事項→期限」を冒頭3行に置く逆ピラミッド型で行う。内容の可否判断はしない、という制約を明確に持たせています。
PM（プロジェクトマネージャー）：案件の実行可能性（運用方針・必要なツール・工数・概算費用）を洗い出し、計画書を作る。実行フェーズでは成果物を「差し戻す理由を先に列挙してから合否判定する」という敵対的な視点でチェックする役割です。
経理：稟議の金銭審査を行う。社内ルールの数値基準と照らして「承認可／差し戻し／上限超過（社長承認要）」を判定し、計算の途中式を必ず残す、という行動規範を持たせています。
開発課：承認済みの計画に基づいて実装・制作を行う。着手前に仕様を復唱してPMに確認する、未完成の成果物を完成として提出しない、対外公開・デプロイは実行しない、という制約があります（本記事はまさにこの開発課の役割で執筆しています）。

全員に共通する行動規範として、「忖度の全面禁止」「悪い報せほど先に報告する」「推測と事実を区別し、未確認は未確認と明記する」を課しています。この記事の中で「未確認」「未検証」という表現が繰り返し出てくるのは、このルールをそのまま適用しているためです。

なお、社則は、秘書とは別に実務部門を統括・経理・企画・PM・開発・営業・広報・監査役の 8区分で定義しています。「4人のAI社員」とは、秘書、および実務部門8区分のうち現時点で独立したエージェントとして実装済みの3役割（PM・経理・開発課）を合わせた4役割を指します。未実装の統括の機能は第1期は秘書が暫定兼務（計画フェーズの全社整合確認・実行フェーズの完了判定を「所感」として添える形）しており、監査役の正確性検証機能は第1期はPMが暫定兼務しています。次章のフローにもこの兼務構造をそのまま反映しています。

4. 2フェーズの意思決定フロー

業務の流れは、計画フェーズと実行フェーズの2段階に分けています。

計画フェーズ（社長の承認はここで1回）：社長指示 → 秘書が起票・フォルダ作成・振り分け → PMが実行可能性を洗い出し → 経理が金銭審査 → 統括が全社整合を確認（第1期は秘書が所感として暫定兼務）→ 秘書が形式確認のうえ社長へ承認依頼 → 社長が計画と予算枠を一括承認、という順番です。

実行フェーズ（承認済みの範囲内は報告のみで進行）：開発課が実装 → PMが品質チェック（第1期は監査役の正確性検証も暫定兼務）→ 統括が完了判定（第1期は秘書が暫定兼務）→ 秘書経由で社長へ完了報告、という順番です。予算枠の超過や仕様変更、対外公開が絡む場合は、再び承認が必要になるルールにしています。

ポイントは、社長が細部まで毎回口を出さなくても、承認された範囲の中でAI社員たちが自律的に手続きを進められるように設計している点です。逆に言えば、その範囲を外れる判断（お金を使う、外部に公開する）は、必ず人間の承認に戻ってくる設計にしています。

5. 実例：このブログ立ち上げ案件で何が起きたか

ここからが本記事の一次情報の核心です。今読んでいただいているこのブログ立ち上げ自体が、上記のフローに沿って実際に動いた案件です。

社長からの指示書が発令され、投資条件（小さめの上限額をあらかじめ想定）、量産禁止・少数高品質・一次情報軸という戦略条件、テーマの最終決定は社長に残す、という条件が明記されました。
秘書が案件用のフォルダを作成し、PMへ振り分けました。
PMが実行可能性を洗い出し、テーマ候補を3案（実機レビュー型／特定領域深掘り型／速報キュレーション型）、それぞれに収益化手段・競合状況・社長の関与度を付けて計画書にまとめました。あわせて、独自ドメイン＋レンタルサーバー構成と無料ブログサービス構成のコスト比較も行っています。
経理が計画書を社内ルールの数値基準と照らして審査し、どちらの構成も基準内であることを、途中式つきで確認しました。
秘書が内容の可否判断はせず形式のみ確認し、承認依頼書として社長へ提出しました。
社長がテーマ最終決定・サイト構成・予算枠を承認し（決定内容は日付・決定者つきで正式に記録済み）、実行フェーズに入りました。これを受けて開発課（本記事の執筆者）が、ブログ開設手順書と第1本目の記事原稿を作成しています。なお、本記事の対外公開自体は、社内ルールに基づく社長の別途の承認プロセスを経て行われるものです。

この一連の流れは、脚本を書いてAIに「うまくいった体で」演じさせたものではなく、実際に案件フォルダ内に生成されたファイル（指示書・計画書・稟議審査結果・承認依頼書）として残っています。これが本記事における「一次情報」の実体です。

6. わかったこと・まだわからないこと

現時点で言えること（構築してみて確認できた事実）

判断基準を数字で先に固定しておくと、金銭審査のような機械的な判定が必要な工程は、 AIエージェントに委ねやすくなります。実際に経理役は基準との対比を数値で示して判定を出しました。
役割ごとにファイルを分けて「してはいけないこと」を明記しておくと、開発課が公開操作を行う、秘書が内容の可否を判断する、といった越権的な動きを、少なくとも今回の1案件では起こさずに済みました。
計画フェーズの成果物（計画書・稟議審査結果・承認依頼書）が、承認前の時点でファイルとしてすべて残るため、「誰が何を根拠にどう判断したか」を後から検証できる状態になっています。

まだわからないこと（正直に「未検証」と明記します）

このキットは本日構築したばかりで、長期運用での効果は一切測定できていません。複数案件を並行させたときに破綻しないか、月日が経ってルールが形骸化しないか、といった点は今後の検証課題です。
コスト（AI利用料・運用の手間）に対して、実際にどれだけ「判断の質」が上がったのかは、定量的に比較できていません。体感の話にとどまります。
本記事の中で紹介した仕組み（社則・エージェント構成）は、あくまでこの1社（1人）の運用に合わせて作ったものであり、他の体制・他の業種にそのまま当てはまるかは未確認です。
収益化については、この案件自体がまだ計画→実行フェーズの途中であり、売上や検索流入といった数値の実績は現時点でゼロで、意図的に何も誇張していません。 段階的なKPI（1〜2ヶ月目は公開記事数と品質、3〜4ヶ月目は検索流入、5〜6ヶ月目は収益）で、今後の記事で追跡していく予定です。

7. まとめと今後の検証予定

一人社長でも、判断基準を先に文書化し、役割ごとに権限を分けたAIエージェントに運用させることで、「毎回自分で全部判断する」状態から一歩離れられる、という手応えはありました。ただしこれはまだ1案件・1日分の実体験にすぎず、効果を主張できる段階にはありません。

今後は、このブログ運用自体を素材にしながら、

複数案件を並行させたときにフローが機能し続けるか
ルールを破りそうになった／破った場面が実際に起きるか（社内の検証・監査の仕組みが機能するか）
数字（工数・コスト・記事の検索流入）がどう推移するか

を、検証日を明記したスナップショット記録として、今後の記事で継続的に追っていきます。

定点観測ログ②（次回）では、①稼働案件数の推移／②社内ルールの改定有無／③品質チェックでの差し戻し件数の推移、の3項目を、本記事（観測日：2026年7月24日時点）からの前回比較として取り上げる予定です。