AIエージェントの業務運用設計
役割・権限・監査・停止条件をどう決めるか
Netsujo株式会社は、京都を拠点とする少人数のスタートアップです。私たちは、AIエージェント（Claude Code）と自動化、そして「事実を仕組みで担保する」品質ゲートを組み合わせることで、少人数でも安定した品質を保つ運用を組んでいます。その運用の中身を実装に即して公開します。
派手なAI活用論より、日々の業務をどう回しているかの実際を重視しています。判断を人間が握り、実装と検証をAIに任せ、誤りは仕組みで止める——この3つを軸にした「運用OS」を、隠さずにお見せします。
この記事の要点
- ▸Netsujoは少人数で、判断は人間・実装と検証はAIエージェント（Claude Code）という役割分担で複数の事業とサイト運用を回しています。
- ▸品質を保つために、事実確認の仕組みを組み込みます。第三者AIによるファクトチェック（運用ルール）、事実誤りを機械的に弾くCI（本番前に自動で強制）、出典必須のProof検証という3つの仕組みで検証します。
- ▸SEO監査・Core Web Vitals・導線分析・独自性監査などを毎週月曜の朝に実行するよう設定しています。実行結果はGitHub Actionsのログと成果物で確認します。
- ▸ポジショニング・公開判断・実績の一次裏取り・倫理の線引きは、人間が握り続けます。
— 01
なぜ「運用OS」が必要だったのか
Netsujoは2023年6月に設立した、京都拠点の少人数スタートアップです。Web3・AIといった先端領域で、コンサルティングだけでなく実装まで踏み込む「実装型BizDev」を掲げています。少人数で複数の事業とサイト運用を抱えると、確認すべきことは指数的に増えていきます。
人の注意力だけでこれを支えようとすると、必ずどこかで漏れます。実際に私たちも、役職の誤表記や日付の取り違えといった誤りを経験しました。そこで、同じ誤りを検知して本番反映前に止める仕組みを運用に組み込むことにしました。
2026年6月、私たちはこの仕組みを社内で「運用OS」と呼び、実装・検証の役割分担を整え始めました。その後、作業状態、変更権限、検証対象、独立レビュー、停止と復旧を別々に管理する設計へ発展させました。公開OSSのAgent Role Contracts 1.0.0では、役割・権限・タスク範囲・レビュアーの宣言に矛盾がないかを実行前に検査できます。実ワークフロー評価の計画では、PASS、意図した矛盾によるFAIL、修正後のPASSの再現性を確かめ、既存のIAM・CI・sandboxとの重複、設定工数、別タスクでの再利用も調べます。宣言の整合性と実行時の権限・副作用の証拠は分けて判断します。当初の運用史と現在の評価範囲を時点とともに示します。
運用を支える主な道具
従来の運用と、運用OSの違い
| 観点 | 従来の運用 | 運用OS |
|---|---|---|
| 品質の担保 | 担当者が「気をつける」 | CI・検証スクリプト・第三者AIで仕組み化 |
| 事実誤りの検知 | レビューで人が気づくまで残る | 禁止パターンに一致するとCIが失敗 |
| SEO/サイトの監視 | 問題が起きてから対処 | 週次監査を登録し、実行・通知は記録で確認 |
| 作業の記録 | 個人の頭の中・チャットに散在 | マークダウン／台帳に残し後から検証可能 |
| 実装スピード | 人手の作業量に比例 | 反復・定型作業をAIと自動化に委譲 |
— 02
運用の3原則
運用OSは、3つのシンプルな原則の上に成り立っています。
判断は人、実装はAI
ポジショニング・公開可否・倫理の判断は人間が握り、調査・コード修正・分析・定型作業はAIエージェントに任せます。役割を明確に分けることで、スピードと責任の所在を両立します。
事実の裏取りを仕組みに組み込む
人の注意力に頼ると誤りは必ず漏れます。出典の必須化、禁止表現の自動検査、第三者AIによるファクトチェックといった仕組みに落とし込み、誤りを機械的に止めます。
全部、記録に残す
決定事項・作業結果・監査結果はGitHubのIssue、PR、検証記録などに残し、対象のコミットや実行結果と照合します。再利用できる判断材料を蓄積します。
— 03
品質を担保する3層ゲート
AIが書いたものをそのまま世に出すことはありません。成果物は、性質の異なる3つの仕組みで検証します。1つは本番前に自動で強制されるCI、ほかは運用ルールと検証スクリプトです。強制力の異なる層を重ねることで、誤りを見つけやすくしています。
codexによる第三者ファクトチェック
書いた当人とは別のAIに読ませて、誤り・誇張・検証できない断定を洗い出します。呼ぶ時点は成果物の種別で分けています。リポジトリ内の差分は、lint・型・テスト・buildの機械検査がPASSしたあとに1回。機械検査では真偽を判定できない成果物（調査・提案・外部公開記事の本文など）は、完了報告の前に1回です。レビュー担当には読み取りだけを許可し、実装・自動修正・commit・pushはさせません。
事実誤りを機械的に弾くCI
役職の誤表記・虚偽の経歴・改名前のサービス名・誤った日付など、過去に実際に起きた誤りを禁止パターンとしてCIに登録しています。該当する記述がコードに混じると、本番へ進む前にCIのチェックが自動で失敗します。この層はCIが自動で落とすため、通過を人の判断で省略できません。
出典を必須にしたProof検証
登壇・受賞・メディア掲載などの実績は、検証可能な出典URLと裏取り日をセットで登録する決まりにし、どちらかが欠けていれば検証スクリプトがエラーで止まります。出典の中身そのものは人間が一次裏取りし、スクリプトは「出典と裏取り日が必ず添えられているか」を担保します。
具体例：誤りが本番前に止まる
たとえば、ある人物の肩書きを実際と違う役職で書いてしまったとします。従来ならレビューで誰かが気づくまで残りますが、その事実ズレは「事実誤りを弾くCI」の禁止パターンに一致し、本番反映の前にCIのチェックが止まります。過去に一度起きた誤りを禁止パターンとして登録しておくことで、同じ誤りは本番前に自動で検知できます。学びを仕組みに変える——これが、私たちが誠実さを保つやり方です。
なぜ「別のAI」に検証させるのか
書いた本人（人でもAIでも）は、自分の思い込みに気づきにくいものです。だからこそ、書いた当人とは別のAIに、リポジトリの実装と突き合わせて検証させます。AIの嘘や誇張をゼロにはできませんが、独立した視点を一段挟むことで、明らかな誤りや検証できない断定を大きく減らせます。
— 04
週次監査の設定と実行確認
品質は一度きりの確認では保てません。Netsujoでは、毎週月曜の朝に複数の監査が動くようGitHub Actionsへ登録し、結果を通知するステップもワークフローへ設定しています。「問題があるか聞かれてから見る」のを避けるための仕組みです。ただし、スケジュール登録、起動、処理の完了、結果、通知はそれぞれ別の状態です。実行記録と通知記録を確認せずに「毎週回っている」「通知済み」とは報告しません。
GSC週次フル監査
Search ConsoleとGA4を統合し、サイトマップ・インデックス状況・CTR低迷・canonical不一致を網羅チェック
Core Web Vitals監査
PageSpeed Insightsでモバイル/デスクトップの表示速度を計測
効果測定（導線分析）
自治体導線・関西Web3まわりの流入と成果をGA4とGSCで分析
IndexNow Ping
主要URLをBing IndexNowへ自動通知し、クロールを促進
llms.txt整合性チェック
AI検索向けに提供しているllms.txtのURL整合性を検査
独自性監査
記事コンテンツの独自性を採点し、薄いコンテンツを検出
「監査が回っている」と言う前に、5つの状態を分けて確認する
| 状態 | 確認できること | これだけでは言えないこと |
|---|---|---|
| 登録 | スケジュールの定義がリポジトリに存在する | 起動したこと |
| 起動 | 対象の時刻に実行が開始された記録がある | 最後まで処理が進んだこと |
| 処理の完了 | 途中で失敗せず終了した記録がある | 中身の判定が正しかったこと |
| 結果 | 判定内容と対象範囲が読み取れる | 担当者へ届いたこと |
| 通知 | 結果が受け取り先へ送られた記録がある | 受け取った人が対応したこと |
上から順に確認します。1つ上が成立していないのに下を報告しない、という順序が要点です。実行記録を見ずに「毎週回っている」と書かないのも、この表の使い方に含まれます。
これらに加えて、コードを本番へ反映する前には「事実誤りを弾くCI」と「コンフリクトの取り残し検査」が自動で走ります。検出された重大な問題はその場で修正し、軽微なものは記録して次のサイクルで対応します。検知から修正までの流れも、できるだけ仕組みに乗せています。
— 05
読み取りだけの担当と、変更する担当を分ける
エージェントを増やすほど、作業状態の管理が重要になります。誰がいま何をしてよいのか、止まっているものをどう再開するのかが決まっていないと、進捗の確認そのものが人間の作業として増えていきます。当社では役割ごとに、権限・停止時に残る操作・再開条件を先に書いています。以下はその設計例です。
| 状態 | できること | できないこと | 再開の条件 |
|---|---|---|---|
| 実行中 | 割り当てられた作業単位の中でファイルを変更し、branchへcommit・pushする | 作業単位の外へ変更を広げる。本番反映の判断を行う | — |
| 読み取りのみ | 渡された差分と既存の記録を読み、指摘を返す | ファイルの変更、自動修正、commit、push | — |
| 停止中 | 既に作られた記録・成果物を読む | セッション開始、実行、自動レビュー、再実行、代理呼び出し | 既定は拒否。承認の識別子・対象範囲・対象commit・上限・期限がすべて揃ったときだけ成立する |
設計上の要点は3つあります。1つ目は、実装した担当が、その実装の独立レビューを兼ねないことです。実装担当が自分の変更を読み、原因を調べ、テストを書くのは必要な作業なので、そこを止めるわけではありません。分けるのは、その確認を独立したレビューとして数えないという一点です。実装の前提が誤っていた場合、同じ担当の確認だけでは、その前提のまま検証が通ります。
2つ目は、停止を能力の剥奪と同一視しないことです。停止は一時的な状態であり、レビュー担当としての資格は保持したままにします。状態と資格を同じ欄で管理すると、止めたあとに元へ戻せなくなります。
3つ目は、再開の既定を拒否にすることです。当社の例では、承認の識別子・対象範囲・対象のcommit・上限・期限がすべて同時に揃ったときだけ再開を成立させ、どれか1つでも欠けていれば再開しません。観測できない値を推測で埋めることもしません。予算が見えないことと、予算が十分にあることは別だからです。なお、この5項目という組み合わせは外部サービスの利用上限に達しうる構成を前提にした当社の設定であり、すべてのAI運用に必要な前提ではありません。
この整理の目的は、人間の判断を維持しながら、進捗確認の中継作業を減らすことです。状態と再開条件が読み取れる形になっていれば、止まっている理由を人が聞いて回らずに済みます。中継がどれだけ減ったかは計測していないため、効果としては報告しません。
ここに書いたのは、当社で使っている状態区分と再開条件の設計例です。どの制約がランタイム側で強制されていて、どこまでが運用上の取り決めかは役割ごとに違います。設計したことと、実際に機械が拒否できることは別に記録しています。組織の規模、扱うデータ、停止したときのコストによって必要な区分は変わるため、この形をそのまま持ち込む前提では書いていません。
— 06
人間が握り続けること
AIに任せるほど、人間が握るべきことが明確になります。次の判断は、仕組みに渡さず人間が責任を持ちます。
ポジショニング・メッセージの決定
公開してよいかの最終判断
事実かどうかの一次裏取り（固有名詞・実績）
倫理・誠実さの線引き
次に何を作るか・何をやめるかの意思決定
この運用OSが目指すのは「人間を減らすこと」ではありません。人間が、判断という最も価値の高い仕事に集中できる状態をつくることです。実装と検証の負荷をAIと仕組みに預けるほど、私たちは「何を作り、誰に届け、どう誠実であるか」に時間を使えます。
— 07
AIに任せて分かったこと（手応えと限界）
AI活用を美化するつもりはありません。実際に運用してみて分かった手応えと、超えられない限界の両方を、正直に書きます。
手応え
- ▸反復作業（一括修正・監査・申請）をAIと自動化へ委譲できる。ただし削減幅は計測しておらず、工数削減率としては報告しない
- ▸仕組みに落とした品質チェックは、人の体調や繁忙に左右されない
- ▸記録が残るため、過去の判断を後から検証・再利用できる
限界・注意
- ▸AIも誇張や思い込みで誤る。第三者チェックと出典の裏取りは外せない
- ▸「何を作るか」「公開してよいか」は仕組みに渡せず、人間の判断が要る
- ▸仕組みづくり自体に初期コストがかかる。小さく始めて育てるのが現実的
— 08
よくある質問（FAQ）
AIエージェントによる運用について、よく寄せられる質問をまとめました。
Q1AIエージェントで会社を回すとは、具体的にどういう状態ですか？
AIエージェントで会社を回すとは、具体的にどういう状態ですか？
判断を人間が握り、調査・コード修正・分析・定型作業・監査をAIエージェント（Claude Code）と自動化スクリプトに任せている状態です。少人数でも、確認や品質チェックを仕組み化することで、見落としを減らし安定した品質を保てます。
Q2AIが書いたものに誤りが混じらないのですか？
AIが書いたものに誤りが混じらないのですか？
AIも人も誤ります。だからこそNetsujoは、書いた当人とは別のAI（codex／GPT）による第三者ファクトチェック（運用ルール）、事実誤りを機械的に弾くCI、出典必須のProof検証という3つの仕組みで検証します。とくに事実誤りを弾くCIは、本番反映の前に自動で走り、該当する記述があればCIのチェックが失敗します。仕組みで誤りを止めることを前提にしています。
Q3codexによるファクトチェックとは何ですか？
codexによるファクトチェックとは何ですか？
OpenAIのcodex CLI（GPT）に、成果物とリポジトリの実装を突き合わせて検証させる工程です。定量的な主張がコードと一致するか、検証できないのに断定していないか、誇張がないかを点検し、指摘を取り込んでから完了とします。
Q4事実誤りを弾くCIとは、どんな仕組みですか？
事実誤りを弾くCIとは、どんな仕組みですか？
過去に実際に起きた誤り（役職の誤表記・虚偽の経歴・改名前のサービス名・誤った日付など）を禁止パターンとして登録した静的検査です。該当する記述がコードに含まれると、本番反映の前にCIのチェックが失敗し、誤りが世に出るのを防ぎます。
Q5どんな週次監査を設定しているのですか？
どんな週次監査を設定しているのですか？
SEO/アクセスのフル監査、Core Web Vitals計測、導線の効果測定、IndexNow通知、llms.txt整合性チェック、コンテンツ独自性監査などを、毎週月曜の朝に実行するスケジュールとしてGitHub Actionsへ登録しています。ただし、登録・起動・完了・結果は別の状態です。実行記録を確認せずに「毎週成功している」とは扱いません。
Q6すべてAIに任せて、人間は何をしているのですか？
すべてAIに任せて、人間は何をしているのですか？
ポジショニングの決定、公開可否の最終判断、固有名詞や実績の一次裏取り、倫理の線引き、次に何を作るかの意思決定は人間の仕事です。AIは実装と検証を担い、人間は方向と責任を担う、という役割分担です。
Q7AIに任せられない領域はどこですか？
AIに任せられない領域はどこですか？
価値観や責任が問われる判断はAIに任せません。具体的には、ブランドのポジショニング、誇張と事実の線引き、外部に公開してよいかの最終判断、そして「何を作り、何をやめるか」という事業の意思決定です。AIは選択肢の整理や実装を高速化しますが、最終的に責任を負うのは人間です。
Q8導入にコストや専門知識は必要ですか？
導入にコストや専門知識は必要ですか？
仕組みづくりには相応の初期コストがかかります。ただし一度に全部を作る必要はありません。たとえば「事実誤りを弾くCI」のように、過去に起きた失敗を1つずつ禁止パターンとして足していけば、運用しながら少しずつ堅牢にできます。小さく始めて育てるのが現実的です。
Q9同じ仕組みは他社でも再現できますか？
同じ仕組みは他社でも再現できますか？
同種の仕組みは、一般的なツール（Claude Code・GitHub Actionsなど）の組み合わせで構成できます。本記事で挙げた要素は、第三者AIによるチェック、禁止パターンのCI、出典必須のデータ構造、定期監査の登録です。ただし他社環境での再現は検証していないため、同じ効果が出ると約束するものではありません。重要なのはツールそのものより、「品質を人の注意力に頼らず、仕組みで担保する」という設計思想です。
現場で使うための判断
AIエージェントで会社を回すというのは、人間を仕組みに置き換えることではありません。判断を人間が握り、実装と検証をAIに任せ、誤りは仕組みで止める——この役割分担を徹底することです。
少人数のスタートアップでも、品質を仕組みに落とし込めば、確認漏れの少ない安定した運用は実現できます。Netsujoはその運用OSを、自社サイトという実物で日々検証しています。自分たちで使う道具を自分たちで作り、誠実さを仕組みで担保する。その積み重ねが、私たちが提供する開発・分析の品質に直結すると考えています。
この記事の著者
飯田 友広
代表取締役
Netsujo株式会社 代表取締役。Technical BizDev / AI Deploymentとして、顧客の業務課題、AI適用領域、PoC、実装チームとの要件、本番導入後の評価をつなぐ。京都発のWeb3・AI実装スタートアップを2023年6月に創業。Webサイトを営業基盤として捉え、経営・営業・検索・生成AI・コンバージョン・計測を横断して課題と改善優先順位を整理する「Netsujo SIGNAL」を設計・運営。さらに、ChatGPT・Codex・Claude Codeを状態再構築、競合回避、独立QC、Exact-head検証、停止、復旧まで含む制御ループで運用する社内AI開発基盤「Netsujo Agent OS」を設計・実運転。Netsujoとして京都ビッグデータ活用プラットフォームに参画(小規模企業会員（ベンチャー）)し、同プラットフォーム発のワーキンググループ「Chain Up KYOTO」にも参画(2026年3月10日〜)。IVS2026サイドイベント「なぜ京都でWeb3.0ビジネスなのか」はNetsujoとして京都府庁旧議場で主催・企画・登壇・運営(2026年7月2日／京都府 総合政策環境部 デジタル政策推進課は共催)。京都美術工芸大学・龍谷大学での講義に加え、京都高度技術研究所（ASTEM）、旅館業界、就労支援施設、Open Source Conference等で登壇実績。ITコミュニティ「みやこでIT」(connpassメンバー639名・イベント176件・2019年2月から運営)運営。NPO法人NEMTUS理事、BAR KRYPTO運営。Netsujoはソーシャル企業認証制度「S認証」の認証企業(2026年2月認証・2026年4月公表)。技術領域はWeb3/ブロックチェーン/DID/NFT/生成AI/コミュニティ運営。
プロフィールを見るこの記事が向いている方
少人数チームでAIを業務に組み込みたい経営者・担当者
AIの出力品質をどう担保するか悩んでいる方
Claude Codeの実務運用に関心のあるエンジニア
