メインコンテンツへスキップ
NetsujoNetsujo Inc.

AI DEVELOPMENT / DELIVERY MAP

AI開発の進め方を、5つの工程で理解する。

依頼、実装、検証、公開、観測。各工程で、何を確認し、誰が実行でき、何を証拠として残すかを、整理しています。

01 / DELIVERY MAP

1つの変更が本番に届くまでの5工程

依頼（Issue）から、変更を提案するPull Request（PR）、自動検証を行うContinuous Integration（CI）とレビュー、公開（Deploy）、公開後の観測まで。工程ごとに、起きやすい失敗と、状態・権限・証拠として確かめることを整理しました。

判断基準：「コードを書いた」「PRを作った」「CIが通った」「mergeした」「本番で動いた」を、同じ意味の“完了”として扱いません。

01依頼するIssue

目的、制約、受入条件を明文化します。AIに渡す前に「何をもって完了とするか」を書いておくと、後の工程でも同じ対象を指して確かめられます。

起きやすい失敗

受入条件が会話の中にしか残っておらず、担当やチャットが変わると、何を満たせば完了なのかを誰も答えられなくなる。

状態
目的・制約・受入条件
権限
誰が着手できるか
証拠
要求と受入条件の記録

この工程で読む

02変更をつくるCommit / PR

変更を履歴として残し、レビューできる単位にします。どのBranchのどのHEADを誰が触っているかを固定すると、並列で作業しても対象を取り違えにくくなります。

起きやすい失敗

複数のAIが同じ作業ツリーで衝突する。Pull Requestがcloseされただけなのに、mergeされたと思い込む。

状態
現在の変更版（Branch・HEAD・PR）
権限
writer / reviewer
証拠
exact SHA・diff

この工程で読む

03確かめるCI / Review

対象の版を固定し、自動検証とレビューを分けて確認します。HEADが変われば検証対象も変わるため、以前のPASSはそのまま使いません。

起きやすい失敗

古いHEADに対するCIやレビューのPASSを、新しい版の合格として扱う。レビューの指摘が終わらず、どこで止めるかの基準がない。

状態
検証した版と、mainへ統合済みか
権限
reviewer / merge authority
証拠
同じSHAに対するCI・レビュー結果、merge commit

この工程で読む

04公開するDeploy

検証済みの成果物を対象環境へ反映します。Deployが成功したことと、公開面で意図した版が動いていることは、別の事実として確かめます。

起きやすい失敗

CIもDeployも成功と表示されているのに、本番では古い版が動いている。人の承認が必要な操作と、AIに任せてよい操作の境界が決まっていない。

状態
どの環境へ反映済みか
権限
deploy authority
証拠
deployment ID・target SHA

この工程で読む

05観測するMonitoring

実際の画面・機能・利用時の状態を確認します。応答が止まったときは、再実行する前に外部の実状態を照合します。

起きやすい失敗

タイムアウトや応答停止を「未実行」と見なして再実行し、二重送信や二重公開を起こす。

状態
公開状態が何か
権限
公開後の変更権限
証拠
HTTP・画面・機能のreadback

この工程で読む

戻る：公開後に結果が分からないときは、再実行する前に状態を読み直す

02 / THREE QUESTIONS

どの工程でも、3つの問いに答える

状態・権限・証拠を分けておくと、担当が交代しても現在地を再構築できます。各項目から、基幹ガイドの該当節へ直接移動します。

03 / CORE GUIDES

3つの基幹ガイドで、運用設計の骨格をつかむ

ブログ記事は実例・事故・実測の記録として残し、長く使う概念は常設の基幹ガイドへ集約しています。

  1. 基幹ガイド 01・実行基盤Agent HarnessEXECUTION ENVIRONMENTInstructions、Tools、Context、実行ループ、Guardrails、Observability、Recoveryを一つの実行基盤として整理します。工程マップ：01・05ガイドを読む
  2. 基幹ガイド 02・統制モデルState・Authority・EvidenceGOVERNANCE MODEL現在状態、実行権限、検証証拠を分離し、PR・Deploy・Productionまで同じ対象を追跡する方法を整理します。工程マップ：02・04ガイドを読む
  3. 基幹ガイド 03・品質管理Independent QCQUALITY CONTROL実装と検証を別runtimeへ分け、Exact HEADを独立に受入する品質管理の考え方を整理します。工程マップ：03ガイドを読む

04 / SYMPTOMS

いま起きている症状から探す

よくある詰まり方から、原因と対処を扱う記事へ直接移動できます。

05 / LEARNING PATH

段階的に学ぶ

GitHubの基礎から本番運用の統制までを、一度に理解する必要はありません。現在の詰まり方に合わせて、必要な段階から読めます。

  1. 段階 1

    まずGitHub上の「現在地」を読めるようにする

    Branch、HEAD、base/head、PR、Checks、merge、deployを分けて理解する段階です。変更がどこにあり、何が検証されたかを読める状態を作ります。

  2. 段階 2

    AIを実行系として設計する

    複数AIの役割、Harness、停止条件、状態保持、権限境界を設計します。モデル選定だけでは解けない問題が中心になります。

  3. 段階 3

    本番へ届けるための統制と復旧を組み込む

    Controller、Orchestrator、Independent QC、Evidence、Gate、Recoveryを使い、終端まで安全に到達できる運用へ移します。速度も同じ運用の中で改善します。

06 / KNOWLEDGE MAP

記事ライブラリを、5つの分類から読む

技術ブログのAI開発記事を、体系・状態統制・失敗学・実測・導入の5分類で整理しました。URLは変えず、各記事からこのページへ戻れます。

体系・実行基盤

FOUNDATION / EXECUTION

AIを使うこと自体ではなく、仕様・役割・Tools・MCP・RAG・並列実行をどう組み立てるかを扱います。

6本

状態・統制

STATE / GOVERNANCE

状態、権限、Evidence、CI、レビュー、承認、Deploy、本番確認を分け、複数AIを安全に終端させるための知見です。

15本

失敗学

INCIDENT / FAILURE

実際に起きた事故を、原因の説明で終わらせずRule、Policy、Gate、Regression Testへ変えた記録です。

4本

実測・変遷

EVIDENCE / EVOLUTION

何セッション動かしたか、何が速くなったか、どこで人間の判断が残ったか。運用の変化を一次情報として残します。

3本

導入・業務接続

ADOPTION / BUSINESS

自社業務へAIを入れるときの診断、RAGや業務ツール接続、相談・導入の入口を扱います。

2本

07 / OPERATING PRINCIPLES

実運用から固定した6つの原則

再発した問題をRule、Test、CI、Gate、Evidenceへ移し、長いプロンプトへの依存を減らすための基準です。

  1. 01

    実装・検証・公開・観測を、一つの「完了」にまとめない

    CIが成功しても、merge・deploy・本番確認は別工程です。どこまで済んだかを別々の証拠で答えられる状態にします。

  2. 02

    検証結果は、必ず対象の版へ結び付ける

    同じPRでもHEADが変われば別の対象です。コミットIDと、その版に対するCI・レビュー・確認結果を対応付けます。

  3. 03

    モデルの賢さと、実務を安全に進める仕組みを分ける

    Model、Agent、Harnessは役割が異なります。道具、文脈、停止条件、権限、観測、復旧は周辺の運用設計で決まります。

  4. 04

    状態・権限・証拠を分けて管理する

    誰が書けるか、今どこまで進んだか、何が確認できたかを分離すると、複数エージェントでも現在地を見失いにくくなります。

  5. 05

    独立QCは、実装者の自己申告を置き換える

    実装と検証を別の実行環境・文脈に分け、同じ対象IDを確認します。対象が変われば、以前のPASSはそのまま再利用しません。

  6. 06

    結果が不明なら、再試行の前に現状を確認する

    タイムアウトや応答停止は「未実行」を意味しません。二重送信や二重公開を避けるため、外部状態を照合してから再開します。

08 / LAYERS & TERMS

用語ではなく、管理対象で層を分ける

GitHubは履歴と共同作業の基盤、HarnessはAIの実行基盤です。Agent OS・Controller・Orchestratorは、Netsujoが責任を重複させないために置いている運用上の役割です。

Git / GitHub / Actions
履歴・共同作業・自動検証
Commit、Branch、PR、Review、CI、Deployの位置関係を理解し、変更と証拠を追跡できるようにします。
Agent Harness
AIを実行環境へつなぐ
Instructions、Tools、Context、実行ループ、Guardrails、Observability、Recoveryを束ねます。
Agent OSNetsujoでの運用定義
Netsujoの運用規範
状態・権限・証拠をどう扱うかを共通ルールとして定めます。Netsujoの運用上の定義で、一般規格を示すものではありません。
ControllerNetsujoでの運用定義
進行可否と実行権を管理
現在状態、writer、通過条件を管理し、BLOCKEDやOUTCOME_UNCERTAINを安易に「失敗」「完了」へ置き換えません。
OrchestratorNetsujoでの運用定義
複数の実行を調整
担当割当、並列実行、復旧、独立検証を調整し、同じ対象への競合や重複作業を抑えます。

※ Agent OS、Controller、Orchestratorの役割分担はNetsujoの運用上の定義です。業界共通の標準や、特定製品の公式名称として示しているものではありません。

09 / PROOF

Netsujo Agent OSの実運転記録

このガイドの原則は、Netsujoが実際に使う制御基盤・運用設計から整理しています。Agent OSのページでは、その構成と検証記録を公開しています。

Agent OSの実運転を見る
このガイド学ぶための入口
AI開発・運用の概念と実務の流れを体系化する常設ハブ
Agent OS実運転の証拠
Netsujoが実際に使う制御基盤・運用設計と、その検証記録
AI実務コミュニティ継続共有の場
イベントや実践知を、人と人の間で継続的に共有する場

10 / FAQ

AI開発・運用でよく出る疑問

AIエージェント開発で最初に難しくなるのは何ですか？

モデルの生成能力より、誰が何を触っているか、どの版を検証したか、どこまで公開されたかを追う状態管理が先に難しくなります。AIを増やすほど、担当・権限・証拠・復旧の設計が重要になります。

Agent Harnessとは何ですか？

本ページでは、モデル呼び出しに加えて、Instructions、Tools、Context、実行ループ、Guardrails、Observability、Recoveryなど、AIを継続的に動かす周辺基盤をまとめてHarnessと呼んでいます。製品や組織によって範囲は異なります。

CIがGREENなら、そのまま本番へ出してよいですか？

いいえ。CIは所定の自動検証が通った証拠であり、merge、deploy、本番動作確認とは別です。検証対象SHA、必要なレビュー、反映先、本番確認を分けて確認します。

ControllerとOrchestratorは同じですか？

Netsujoでは分けています。Controllerは現在状態と進行可否・実行権を管理し、Orchestratorは複数の担当割当、並列実行、復旧、独立検証を調整します。これはNetsujoの運用上の役割分担です。

独立QCは、通常のコードレビューと何が違いますか？

実装者と異なる実行環境・文脈から、同じ対象IDを検証することを重視します。差分だけでなく、テスト、実画面、運用上のリスクまで確認し、対象が変われば再検証します。

このガイドとAgent OS、AI実務コミュニティはどう違いますか？

このガイドはAI開発・運用を体系的に学ぶ常設ハブ、Agent OSはNetsujoの実運転と制御設計の証拠、AI実務コミュニティはイベントや実践知を継続共有する場です。それぞれ役割を分け、相互に接続しています。

NEXT STEP

AI導入を、運用できる形へ落とす

PoCの受入条件、複数AIの役割分担、品質ゲート、権限分離、復旧、本番観測まで。Netsujo自身のAI開発運用で得た知見を、個別の業務・開発プロセスへ適用します。

AI開発・運用について相談する AI社会実装の支援を見る AI実務コミュニティを見る