DEV Community: Stratum Praxis

AI codingは速いのに売上が増えない理由 CodexをRevenue Loopへ接続する

Stratum Praxis — Sun, 13 Sep 2026 00:02:07 +0000

Codexのようなcoding agentを使うと、実装速度は上げやすくなります。

Repositoryを読み、commandsを実行し、testsを回し、変更を出す。

OpenAI自身もCodexを、repository内で開発作業を進めるcoding agentとして説明しています。

でも、ここには大きな勘違いがあります。

実装速度が上がることと、Revenueが増えることは同じではありません。

BUILDとREVENUEを分ける

AI codingを使うと、完成物が増えます。

LP。
Web tool。
記事。
Checkout。
自動化。

ところが、

BUILD
SHIP
SIGNAL
REVENUE

は全部別です。

LPを作ったらBUILD。
公開したらSHIP。
人がCTAを押したらSIGNAL。
Purchaseが確認できて初めてREVENUE。

この区別がないと、コードの量が事業の進捗に見えてしまいます。

GitHubから始めない

以前は、

Idea
→ GitHub
→ Build
→ Deploy

で進めがちでした。

今は順番を変えます。

市場
↓
GitHub
↓
外部行動
↓
Buyer
↓
Revenue
↓
GitHub
↓
学習
↺

最初に見るのは市場です。

誰が困っているか。
何にお金が払われているか。
どこでBuyerが止まっているか。

そのSignalを受けて、既存Assetの最小変更だけを実装します。

Codexへ渡す仕事を変える

「この機能を作って」ではなく、

このBuyer SignalをRevenueへ1段近づけるために、既存Assetのどこを最小変更すべきか確認し、実装・検証・Evidence保存まで進める

という仕事へ変えます。

Codexの得意な実装能力を、制作量ではなくRevenue Distanceへ向けます。

新しいものを作らない

AI codingで怖いのは、作るコストが下がったことで、作る理由まで軽くなることです。

次の場合は、新商品を作らない方がよい可能性があります。

既存Assetで需要を受けられる
CTAが壊れているだけ
Buyerがまだ確認できていない
Checkoutより手前で止まっている
Purchase Evidenceがない

先に直す、出す、話す、計測する。

同じ欠損が繰り返しEvidenceとして出てから、新しいAssetを検討します。

GitHubへ戻すのは売上ではなく学習

RevenueそのもののSource of Truthは、Stripeや販売プラットフォームです。

GitHubへ戻すのは、

何を変えたか
どんな外部行動をしたか
Human Signalが出たか
どこで落ちたか
次に何を変えるか

という学習可能な差分です。

これでGitHubはコード置き場ではなく、次の外部行動を改善するための実装Evidenceになります。

AIを増やす前に、Revenue Loopを閉じる

新しいAgent、新しいTool、新しい自動化を増やす前に、

Market → Build → Ship → Signal → Revenue → Learn

が一周するかを見る。

Revenueが出なければ、それはAIが失敗したとは限りません。

市場、Offer、Distribution、Timingなど、外部要因もあります。

だからこそ、Code VolumeではなくExternal Evidenceを見る必要があります。

実際にCodexへ渡せるRevenue Task Template、Evidence Pack、STOP条件、7日間Sprintは既存の有料noteへ追記しています。

https://note.com/deft_eel6718/n/n6643ede87ad3

Sources

OpenAI Codex:
https://openai.com/index/introducing-codex/

Running Codex safely at OpenAI:
https://openai.com/index/running-codex-safely/

AIで作る前に、Revenueの詰まりを直す売れないパイプの診断法

Stratum Praxis — Sun, 13 Sep 2026 00:02:03 +0000

AIで作れるものが増えると、売上が出ないときの反応も変わります。

以前なら、制作コストが高いので簡単には新商品を増やせませんでした。

今は数時間で、

記事
LP
Tool
PDF
小さなSaaS

を作れてしまいます。

そのため、売れないときに「次のものを作る」という行動が取りやすくなります。

でもRevenue Routeがすでにあるなら、先に見るべきなのは新商品ではなくDropです。

Revenueを細かく見る

Impression
↓
Visit
↓
Useful Action
↓
CTA
↓
Checkout
↓
Purchase
↓
Repeat

このどこで落ちているかで、直す場所が変わります。

Impressionはある、Visitがない

Title、thumbnail、search intent、distribution channelを見る。

この状態でCheckoutを改善しても、そこまで人が来ていません。

Visitはある、CTAがない

無料Valueと有料Offerのつながりを見る。

「役に立った。でも次はいらない」状態になっていないかを確認します。

CTAはある、Checkoutがない

Price shock、Offer説明、Destination、信頼を見る。

Checkoutはある、Purchaseがない

最後の摩擦を見ます。

ただし、自分のtest clickやvalidation trafficが混ざっていないかを先に確認します。

LikeやReplyはRevenueではない

運用では、途中の反応を分けます。

Like = Human Signal
Visit = Human Signal
Reply = Human Signal
CTA = Human Signal
Checkout = Strong Signal
Purchase = Revenue

この区別を厳しくすると、「反応があったから売れているはず」という判断を避けやすくなります。

新商品を作る前の条件

新商品を検討するのは、

同じPainが反復している
既存Assetでは解決できない
Human Signalがある
不足が複数回Evidenceとして出た

ときです。

「AIで作れそう」は理由にしません。

72時間だけ直す

一つのRouteを無限改善しないために、

0〜24時間でDropを特定。
24〜48時間で最小修正。
48〜72時間で外部反応を見る。

動かなければ、同じ場所を何度も直さず、上流または別Routeへ移ります。

重要なのは一番Revenueに近い0点

Trafficが足りない。
CTAが弱い。
Checkoutが落ちる。
Purchaseがない。

全部を同時に直す必要はありません。

今のRouteで、Revenueに一番近い欠損を一つだけ選ぶ。

それが、AIの制作能力を「作る量」ではなく「Revenueへ近づく修正」へ向ける方法です。

完全なLeak Diagnosis Matrix、Weekly Pipeline Sheet、Route Switching Ruleは既存の有料noteに追記しています。

https://note.com/deft_eel6718/n/nc120a3159186

AIを増やす前に、引き継ぎを作る ChatGPT・Claude・Codexを止めないHandoff設計

Stratum Praxis — Sun, 13 Sep 2026 00:01:26 +0000

ChatGPT、Claude、Codexを使い分けると、できることは増えます。

ところがAIを増やした後に、人間側の仕事が減らないことがあります。

原因の一つは、モデル性能ではなく仕事の受け渡しです。

ChatGPTで調べた内容をClaudeへ説明し直す。
Claudeで決めた仕様をCodexへ渡す。
Codexが実装した後、「どこまで本当に終わったのか」をもう一度確認する。

個々のAIは速くても、この引き継ぎが毎回人間頼みなら、全体の流れはそこで止まります。

継続機能があっても、別のAIへ状態が自動移植されるわけではない

現在のAIツールには、継続作業を支える仕組みがあります。

ChatGPTのProjectsでは、プロジェクト内のチャット、ファイル、指示などをまとめ、継続的な作業コンテキストとして利用できます。

Claude CodeにもCLAUDE.mdなどのプロジェクトメモリや、会話をcontinue / resumeする仕組みがあります。

これらは便利です。

しかし、ChatGPTの状態がそのままClaudeへ、Claudeの状態がそのままCodexへ、さらに実装結果が外部サービスへ自動的に同じ意味で引き継がれるわけではありません。

別の担当・別のセッション・別の実行環境をまたぐときには、共有できる形へ状態を落とす必要があります。

会話の要約より「現在状態」を渡す

引き継ぎでありがちなのが、過去の会話を長く要約する方法です。

でも次の担当が本当に知りたいのは、歴史全部ではありません。

最終目的
現在地
作業済み
何を根拠に確認したか
未完了
すでに却下した案
次にやること

です。

特に重要なのは、

DONEとVERIFIEDを分けること。

「記事を書いた」はDONE。
「noteで公開URLを確認した」はVERIFIED。

「コードを書いた」はDONE。
「Productionで動作を確認した」はVERIFIED。

「Checkoutを開いた」はDONEでも、Purchaseではありません。

この区別がないと、AIの自己申告がそのまま次工程へ渡り、途中状態が完成状態として扱われやすくなります。

HandoffだけでなくAcceptanceを作る

引き継ぎ文書を作るだけでも不十分です。

送り手が間違えている可能性があるからです。

そこで、

WORK → HANDOFF → ACCEPTANCE → WORK

という流れにします。

受け手は、引き継ぎを読んだらすぐ新しい仕事を始めず、重要ファイル、URL、テスト結果などを確認します。

そのうえで、

ACCEPTED
ACCEPTED WITH CORRECTIONS
REJECTED

のどれかを返します。

この一段を入れることで、「前のAIが言っていたから」という理由だけで状態が引き継がれるのを防ぎやすくなります。

GitHubは会話置き場ではなく、実装Evidenceの受け渡し地点にする

GitHubへAIとの会話を全部保存する必要はありません。

残す価値が高いのは、

変更されたファイル
commit
test result
実装上の決定
再現できるEvidence

です。

RevenueそのものはStripeなどのCommerce側がSource of Truthになります。

GitHubへ戻すのは、何を変えた結果、どんな市場反応が出たかという学習可能な差分です。

すると全体は、

市場
↓
GitHub / 実装
↓
外部行動
↓
Buyer
↓
Revenue
↓
Evidence
↓
GitHubへ学習可能な差分
↓
次の外部行動
↺

という循環にできます。

役割を増やすより、受け渡しを固定する

AI活用では、新しいモデル、新しいAgent、新しい自動化ツールを追加したくなります。

でも、既存のAI同士で仕事が正しく渡っていないなら、人数を増やすほど交通整理が増える可能性があります。

先に固定したいのは、

誰が考えるか
誰が実装するか
何をEvidenceとするか
誰が受け取るか
どの状態なら次へ進めるか

です。

この設計ができてから、必要なAIだけ追加する方が扱いやすくなります。

実際に使えるテンプレート

既存のVector有料noteでは、ここで扱った考え方を実務へ落とした、

AI引き継ぎ票
受入確認フォーマット
DONE / VERIFIED分類
ChatGPT → Claude例
Claude → Codex例
Codex → ChatGPT / MARKET例
状態不一致のCorrection Rule

を追加しています。

既存記事:
https://note.com/deft_eel6718/n/ncaff8351e529

テンプレートが不要なら、このGhost記事の考え方だけでも十分始められます。

Sources

OpenAI Projects:
https://help.openai.com/en/articles/10169521-projects-in-chatgpt

Claude Code memory:
https://docs.anthropic.com/zh-CN/docs/claude-code/memory

Claude Code CLI:
https://docs.anthropic.com/en/docs/claude-code/cli-usage

Claude Code handoff request:
https://github.com/anthropics/claude-code/issues/11455
https://github.com/anthropics/claude-code/issues/59492

AI社員を増やす前に、権限と停止条件を決める Agent Operating Constitution

Stratum Praxis — Sun, 13 Sep 2026 00:01:25 +0000

AIに役割を付けるのは簡単です。

Research担当。
Writer担当。
Sales担当。
QA担当。

でもRole名だけでは運用になりません。

必要なのは、

Role + Permission + Approval + Evidence + Escalation + Stop

です。

Role名より境界を決める

AIに「営業担当」と名前を付けても、

誰へ送っていいか
何件まで送っていいか
どの内容なら自動送信してよいか
契約条件を変更してよいか
どこで人間確認が必要か

が決まっていなければ危険です。

Actionを3段階に分ける

GREEN
低リスク。自動実行可。

YELLOW
条件付き。Evidenceまたは承認が必要。

RED
高リスク。Human Gateまたは禁止。

すべてをAIに任せる必要も、すべて人間が確認する必要もありません。

Human Gateを決める

たとえば、

Money
Identity
Contract
Sensitive Data
Irreversible Change
High Reputation Risk

は明示的な承認対象にする。

一方、公開情報のResearchや低リスクの反復処理は、利用中のサービスとpolicyが許す範囲で自動化できます。

Evidence Contractを作る

AIの「完了しました」をそのまま信じません。

記事を書いた = DONE
public URLを確認 = VERIFIED

code changed = DONE
test / target environment確認 = VERIFIED

CTA click = SIGNAL
Purchase = REVENUE

Roleごとに完了の意味を揃えることで、次工程へ誤った状態が渡りにくくなります。

Escalationを整える

Agentが止まったとき、

「どうしますか？」

だけでは人間の仕事が増えます。

最低限、

Goal
Current State
Blocker
Evidence
Options
Recommended
Human Action
Resume Point

を返させる。

これなら人間はGateだけ越え、AIはそこから再開できます。

FailureはTraceへ変える

失敗をゼロにするのではなく、

Detect → Stop → Preserve → Classify → Rollback → Learn → Resume

の流れを用意します。

同じ失敗が繰り返されないよう、Failure Traceを次のEvalやRegression Testへ変える。

Agentを増やさない

新しいAgentは、同じ欠損が何度も起き、既存Roleでは処理できないことがEvidenceで確認されたときだけ追加します。

「面白そう」「便利そう」は理由にしません。

AIを社員のように扱う本当の意味

人格を付けることではありません。

担当範囲
権限
禁止事項
完了条件
Evidence
Escalation
Stop条件
Outcome

を持たせることです。

完全版のAgent Role Charter、Permission Matrix、Approval Gate、Evidence Contract、Failure / Rollback Protocolは既存noteへ追記しています。

https://note.com/deft_eel6718/n/nfce5ac047c15

Sources

Running Codex safely at OpenAI:
https://openai.com/index/running-codex-safely/

OpenAI Presence:
https://openai.com/index/introducing-openai-presence/

OpenAI Presence Help:
https://help.openai.com/en/articles/20001405

AI codingは速いのに売上が増えない理由 CodexをRevenue Loopへ接続する

Stratum Praxis — Sat, 12 Sep 2026 22:16:10 +0000

Codexのようなcoding agentを使うと、実装速度は上げやすくなります。

Repositoryを読み、commandsを実行し、testsを回し、変更を出す。

OpenAI自身もCodexを、repository内で開発作業を進めるcoding agentとして説明しています。

でも、ここには大きな勘違いがあります。

実装速度が上がることと、Revenueが増えることは同じではありません。

BUILDとREVENUEを分ける

AI codingを使うと、完成物が増えます。

LP。
Web tool。
記事。
Checkout。
自動化。

ところが、

BUILD
SHIP
SIGNAL
REVENUE

は全部別です。

LPを作ったらBUILD。
公開したらSHIP。
人がCTAを押したらSIGNAL。
Purchaseが確認できて初めてREVENUE。

この区別がないと、コードの量が事業の進捗に見えてしまいます。

GitHubから始めない

以前は、

Idea
→ GitHub
→ Build
→ Deploy

で進めがちでした。

今は順番を変えます。

市場
↓
GitHub
↓
外部行動
↓
Buyer
↓
Revenue
↓
GitHub
↓
学習
↺

最初に見るのは市場です。

誰が困っているか。
何にお金が払われているか。
どこでBuyerが止まっているか。

そのSignalを受けて、既存Assetの最小変更だけを実装します。

Codexへ渡す仕事を変える

「この機能を作って」ではなく、

このBuyer SignalをRevenueへ1段近づけるために、既存Assetのどこを最小変更すべきか確認し、実装・検証・Evidence保存まで進める

という仕事へ変えます。

Codexの得意な実装能力を、制作量ではなくRevenue Distanceへ向けます。

新しいものを作らない

AI codingで怖いのは、作るコストが下がったことで、作る理由まで軽くなることです。

次の場合は、新商品を作らない方がよい可能性があります。

既存Assetで需要を受けられる
CTAが壊れているだけ
Buyerがまだ確認できていない
Checkoutより手前で止まっている
Purchase Evidenceがない

先に直す、出す、話す、計測する。

同じ欠損が繰り返しEvidenceとして出てから、新しいAssetを検討します。

GitHubへ戻すのは売上ではなく学習

RevenueそのもののSource of Truthは、Stripeや販売プラットフォームです。

GitHubへ戻すのは、

何を変えたか
どんな外部行動をしたか
Human Signalが出たか
どこで落ちたか
次に何を変えるか

という学習可能な差分です。

これでGitHubはコード置き場ではなく、次の外部行動を改善するための実装Evidenceになります。

AIを増やす前に、Revenue Loopを閉じる

新しいAgent、新しいTool、新しい自動化を増やす前に、

Market → Build → Ship → Signal → Revenue → Learn

が一周するかを見る。

Revenueが出なければ、それはAIが失敗したとは限りません。

市場、Offer、Distribution、Timingなど、外部要因もあります。

だからこそ、Code VolumeではなくExternal Evidenceを見る必要があります。

実際にCodexへ渡せるRevenue Task Template、Evidence Pack、STOP条件、7日間Sprintは既存の有料noteへ追記しています。

https://note.com/deft_eel6718/n/n6643ede87ad3

Sources

OpenAI Codex:
https://openai.com/index/introducing-codex/

Running Codex safely at OpenAI:
https://openai.com/index/running-codex-safely/

AIで作る前に、Revenueの詰まりを直す売れないパイプの診断法

Stratum Praxis — Sat, 12 Sep 2026 22:15:34 +0000

AIで作れるものが増えると、売上が出ないときの反応も変わります。

以前なら、制作コストが高いので簡単には新商品を増やせませんでした。

今は数時間で、

記事
LP
Tool
PDF
小さなSaaS

を作れてしまいます。

そのため、売れないときに「次のものを作る」という行動が取りやすくなります。

でもRevenue Routeがすでにあるなら、先に見るべきなのは新商品ではなくDropです。

Revenueを細かく見る

Impression
↓
Visit
↓
Useful Action
↓
CTA
↓
Checkout
↓
Purchase
↓
Repeat

このどこで落ちているかで、直す場所が変わります。

Impressionはある、Visitがない

Title、thumbnail、search intent、distribution channelを見る。

この状態でCheckoutを改善しても、そこまで人が来ていません。

Visitはある、CTAがない

無料Valueと有料Offerのつながりを見る。

「役に立った。でも次はいらない」状態になっていないかを確認します。

CTAはある、Checkoutがない

Price shock、Offer説明、Destination、信頼を見る。

Checkoutはある、Purchaseがない

最後の摩擦を見ます。

ただし、自分のtest clickやvalidation trafficが混ざっていないかを先に確認します。

LikeやReplyはRevenueではない

運用では、途中の反応を分けます。

Like = Human Signal
Visit = Human Signal
Reply = Human Signal
CTA = Human Signal
Checkout = Strong Signal
Purchase = Revenue

この区別を厳しくすると、「反応があったから売れているはず」という判断を避けやすくなります。

新商品を作る前の条件

新商品を検討するのは、

同じPainが反復している
既存Assetでは解決できない
Human Signalがある
不足が複数回Evidenceとして出た

ときです。

「AIで作れそう」は理由にしません。

72時間だけ直す

一つのRouteを無限改善しないために、

0〜24時間でDropを特定。
24〜48時間で最小修正。
48〜72時間で外部反応を見る。

動かなければ、同じ場所を何度も直さず、上流または別Routeへ移ります。

重要なのは一番Revenueに近い0点

Trafficが足りない。
CTAが弱い。
Checkoutが落ちる。
Purchaseがない。

全部を同時に直す必要はありません。

今のRouteで、Revenueに一番近い欠損を一つだけ選ぶ。

それが、AIの制作能力を「作る量」ではなく「Revenueへ近づく修正」へ向ける方法です。

完全なLeak Diagnosis Matrix、Weekly Pipeline Sheet、Route Switching Ruleは既存の有料noteに追記しています。

https://note.com/deft_eel6718/n/nc120a3159186

AI Is Not Your Bottleneck. Your Organization Is.

Stratum Praxis — Sat, 12 Sep 2026 22:15:30 +0000

AI can now produce more work than many organizations can absorb. The next competitive advantage is not generation. It is throughput.

AI has become extraordinarily good at producing work.

It can write the memo, generate the code, draft the campaign, summarize the research, design the workflow, propose the experiment, and produce ten alternatives before a human team has finished its first meeting.

And yet a strange thing keeps happening inside companies adopting AI:

Output rises. Revenue does not rise with it.

The usual response is to blame the model. Maybe the prompts need work. Maybe the company needs a stronger model, more context, another agent, or a better orchestration layer.

Sometimes that is true.

But increasingly, the model is not the bottleneck.

The organization is.

Before generative AI, production capacity was scarce. Research took time. Writing took time. Analysis, design, coding, coordination, and revision all consumed expensive human hours. Making any of those activities faster could create obvious value.

AI changes that constraint. It makes many forms of production cheap and abundant.

But abundance exposes everything downstream.

The draft still needs a decision.
The decision still needs an owner.
The owner may still need approval.
The approved work still needs to be shipped.
The shipped work still needs distribution.
The distribution still needs measurement.
The measurement still needs to change the next action.

The operating equation has changed:

AI Output × Organizational Throughput = Business Value

If organizational throughput is low, multiplying AI output produces surprisingly little economic value.

The bottleneck moved downstream

Most AI strategies focus on the left side of the system:

Prompt → Model → Output

But businesses make money on the right side:

Output → Decision → Execution → Evidence → Revenue

That distinction explains why a team can feel dramatically more productive while the economics barely move.

The organization has built a faster factory feeding the same old loading dock.

Ten reports arrive instead of one. Twenty campaign concepts appear instead of three. Hundreds of leads can be enriched. Dozens of product changes can be proposed.

But if one manager must inspect everything, if publishing still requires five manual steps, if nobody owns the next action, or if analytics cannot connect execution to conversion, AI simply creates a larger queue.

The faster generation becomes, the more visible that queue becomes.

And eventually, the queue becomes the real product problem.

Faster AI makes organizational friction more expensive

Consider a slow approval process.

When one employee produces one proposal per day, a two-day approval delay is annoying.

When an agent system can produce fifty proposals per hour, the same approval process becomes catastrophic. The organization cannot consume what its machines can produce.

This is the paradox of AI leverage:

The faster generation becomes, the more expensive organizational friction becomes.

That means improving the model can actually make a poorly designed operating system feel worse. More intelligence enters the company, but the pathways that convert intelligence into action remain fixed.

The result is not leverage. It is congestion.

This is why adding another agent often disappoints. The company does not necessarily need another intelligence source. It may need a shorter path from intelligence to reality.

Throughput is the missing AI metric

Companies measure AI adoption with convenient numbers:

hours saved;
prompts run;
assets generated;
agents deployed;
tasks automated.

Those numbers describe production capacity. They do not necessarily describe business throughput.

A more useful question is:

How quickly can a useful machine-generated signal become a verified real-world result?

That journey might look like this:

Signal → Analysis → Decision → Action → Evidence → Revenue

Every handoff introduces latency. Every unclear owner introduces waiting. Every unnecessary approval introduces friction. Every manual copy-and-paste step creates dependency. Every missing measurement point makes the organization less capable of learning from what it shipped.

Throughput therefore depends on more than model speed.

It depends on whether the organization can decide, execute, verify, and learn at approximately the same speed that AI can generate.

Most cannot yet.

The unit of automation should be the closed loop

This changes what companies should automate.

A weak automation looks like this:

Request → Generate → Done

The system produced something, so the automation is considered successful.

But nothing necessarily changed in the world.

A stronger automation looks like this:

Goal → Generate → Decide → Execute → Verify → Measure → Improve

The output is not the endpoint. It is an intermediate state.

The workflow is complete only when the work reaches reality and the result can influence the next action.

This is why the useful unit of AI automation is not the task.

It is the closed loop.

At minimum, an important AI workflow needs:

A measurable objective. Not “use AI,” but increase qualified leads, reduce resolution time, improve checkout completion, or raise retention.
A decision rule. What happens when the system produces an answer? Who or what decides GO, ITERATE, REDIRECT, or KILL?
An execution path. The output must be able to change reality: publish, send, deploy, update, contact, deliver, or transact.
Evidence. The action should leave proof: a public URL, commit, delivery receipt, event, lead, conversion, or payment.
A feedback loop. Measurement must alter the next run. Otherwise automation is merely repetition.

Without these pieces, an AI agent is often just a very fast worker placing documents on somebody else's desk.

Human involvement should be intentional, not inherited

None of this means removing humans from every workflow.

Judgment, accountability, taste, relationships, ambiguity, and irreversible risk can justify human gates. In many cases they should.

The important distinction is whether a human is present because the decision genuinely requires a human or because the organization never redesigned an old process.

A person approving a high-risk financial action may be essential.

A person manually copying an approved paragraph from one system into another probably is not.

A person deciding whether a sensitive public claim is appropriate may be essential.

A person checking every routine output because the workflow has no explicit quality gate probably indicates a design problem.

The objective is not maximum autonomy.

It is minimum unnecessary dependency.

That principle matters because every unnecessary dependency becomes more expensive as AI production accelerates.

Measurement is part of throughput

Execution alone is not enough.

A company can automate publishing, outreach, product changes, or customer workflows and still remain strategically blind if it cannot connect those actions to outcomes.

That means measurement cannot be bolted onto the system at the end.

Observability is part of organizational throughput.

A closed loop should be able to answer four questions:

What happened?

What evidence proves it happened?

What economic result followed?

What should change on the next run?

If the system cannot answer those questions, scaling automation may scale activity faster than knowledge.

And activity without knowledge is a dangerous form of apparent progress.

The practical throughput test

There is a simple way to find the real bottleneck in almost any AI workflow.

Start with the model's output and ask:

What happens next?

Then keep asking.

Who reviews it?

What decision is made?

Who owns that decision?

What system executes it?

Does execution require another person?

How does the work reach the customer or market?

What proves that it happened?

How is the outcome measured?

What happens when the result is weak?

Who owns the next action?

Eventually you will reach a point where the workflow stops and waits.

That waiting point is your constraint.

It may be approval. It may be distribution. It may be missing permissions. It may be poor instrumentation. It may be unclear ownership. It may be a manual process nobody has questioned for three years.

Whatever it is, improving that constraint may create more business value than another round of prompt optimization.

Fix it.

Run the loop again.

Find the next constraint.

Repeat.

The next AI advantage is organizational throughput

The AI race is usually described as a race for intelligence.

For model companies, that is largely true.

For operating businesses, the more important race is becoming a race for throughput.

Who can convert intelligence into a verified action fastest?

Who can make decisions without unnecessary waiting?

Who can execute without fragile manual handoffs?

Who can prove what happened?

Who can connect the result to revenue, cost, quality, or speed?

Who can identify the next constraint and improve the loop without rebuilding the entire organization?

As AI output becomes abundant, those capabilities become scarce.

The winners will not necessarily be the companies with the largest collection of agents.

They will be the companies with the shortest reliable distance between:

intelligence → decision → action → evidence → revenue

That is organizational throughput.

And increasingly, that—not generation—is the real AI advantage.

Stratum Praxis explores AI systems, automation, and the operating infrastructure that turns machine intelligence into measurable business outcomes.

AIを増やす前に、引き継ぎを作る ChatGPT・Claude・Codexを止めないHandoff設計

Stratum Praxis — Sat, 12 Sep 2026 22:14:23 +0000

ChatGPT、Claude、Codexを使い分けると、できることは増えます。

ところがAIを増やした後に、人間側の仕事が減らないことがあります。

原因の一つは、モデル性能ではなく仕事の受け渡しです。

個々のAIは速くても、この引き継ぎが毎回人間頼みなら、全体の流れはそこで止まります。

継続機能があっても、別のAIへ状態が自動移植されるわけではない

現在のAIツールには、継続作業を支える仕組みがあります。

ChatGPTのProjectsでは、プロジェクト内のチャット、ファイル、指示などをまとめ、継続的な作業コンテキストとして利用できます。

Claude CodeにもCLAUDE.mdなどのプロジェクトメモリや、会話をcontinue / resumeする仕組みがあります。

これらは便利です。

別の担当・別のセッション・別の実行環境をまたぐときには、共有できる形へ状態を落とす必要があります。

会話の要約より「現在状態」を渡す

引き継ぎでありがちなのが、過去の会話を長く要約する方法です。

でも次の担当が本当に知りたいのは、歴史全部ではありません。

最終目的
現在地
作業済み
何を根拠に確認したか
未完了
すでに却下した案
次にやること

です。

特に重要なのは、

DONEとVERIFIEDを分けること。

「記事を書いた」はDONE。
「noteで公開URLを確認した」はVERIFIED。

「コードを書いた」はDONE。
「Productionで動作を確認した」はVERIFIED。

「Checkoutを開いた」はDONEでも、Purchaseではありません。

この区別がないと、AIの自己申告がそのまま次工程へ渡り、途中状態が完成状態として扱われやすくなります。

HandoffだけでなくAcceptanceを作る

引き継ぎ文書を作るだけでも不十分です。

送り手が間違えている可能性があるからです。

そこで、

WORK → HANDOFF → ACCEPTANCE → WORK

という流れにします。

受け手は、引き継ぎを読んだらすぐ新しい仕事を始めず、重要ファイル、URL、テスト結果などを確認します。

そのうえで、

ACCEPTED
ACCEPTED WITH CORRECTIONS
REJECTED

のどれかを返します。

この一段を入れることで、「前のAIが言っていたから」という理由だけで状態が引き継がれるのを防ぎやすくなります。

GitHubは会話置き場ではなく、実装Evidenceの受け渡し地点にする

GitHubへAIとの会話を全部保存する必要はありません。

残す価値が高いのは、

変更されたファイル
commit
test result
実装上の決定
再現できるEvidence

です。

RevenueそのものはStripeなどのCommerce側がSource of Truthになります。

GitHubへ戻すのは、何を変えた結果、どんな市場反応が出たかという学習可能な差分です。

すると全体は、

市場
↓
GitHub / 実装
↓
外部行動
↓
Buyer
↓
Revenue
↓
Evidence
↓
GitHubへ学習可能な差分
↓
次の外部行動
↺

という循環にできます。

役割を増やすより、受け渡しを固定する

AI活用では、新しいモデル、新しいAgent、新しい自動化ツールを追加したくなります。

でも、既存のAI同士で仕事が正しく渡っていないなら、人数を増やすほど交通整理が増える可能性があります。

先に固定したいのは、

誰が考えるか
誰が実装するか
何をEvidenceとするか
誰が受け取るか
どの状態なら次へ進めるか

です。

この設計ができてから、必要なAIだけ追加する方が扱いやすくなります。

実際に使えるテンプレート

既存のVector有料noteでは、ここで扱った考え方を実務へ落とした、

AI引き継ぎ票
受入確認フォーマット
DONE / VERIFIED分類
ChatGPT → Claude例
Claude → Codex例
Codex → ChatGPT / MARKET例
状態不一致のCorrection Rule

を追加しています。

既存記事:
https://note.com/deft_eel6718/n/ncaff8351e529

テンプレートが不要なら、このGhost記事の考え方だけでも十分始められます。

Sources

OpenAI Projects:
https://help.openai.com/en/articles/10169521-projects-in-chatgpt

Claude Code memory:
https://docs.anthropic.com/zh-CN/docs/claude-code/memory

Claude Code CLI:
https://docs.anthropic.com/en/docs/claude-code/cli-usage

Claude Code handoff request:
https://github.com/anthropics/claude-code/issues/11455
https://github.com/anthropics/claude-code/issues/59492

AI社員を増やす前に、権限と停止条件を決める Agent Operating Constitution

Stratum Praxis — Sat, 12 Sep 2026 22:14:22 +0000

AIに役割を付けるのは簡単です。

Research担当。
Writer担当。
Sales担当。
QA担当。

でもRole名だけでは運用になりません。

必要なのは、

Role + Permission + Approval + Evidence + Escalation + Stop

です。

Role名より境界を決める

AIに「営業担当」と名前を付けても、

誰へ送っていいか
何件まで送っていいか
どの内容なら自動送信してよいか
契約条件を変更してよいか
どこで人間確認が必要か

が決まっていなければ危険です。

Actionを3段階に分ける

GREEN
低リスク。自動実行可。

YELLOW
条件付き。Evidenceまたは承認が必要。

RED
高リスク。Human Gateまたは禁止。

すべてをAIに任せる必要も、すべて人間が確認する必要もありません。

Human Gateを決める

たとえば、

Money
Identity
Contract
Sensitive Data
Irreversible Change
High Reputation Risk

は明示的な承認対象にする。

一方、公開情報のResearchや低リスクの反復処理は、利用中のサービスとpolicyが許す範囲で自動化できます。

Evidence Contractを作る

AIの「完了しました」をそのまま信じません。

記事を書いた = DONE
public URLを確認 = VERIFIED

code changed = DONE
test / target environment確認 = VERIFIED

CTA click = SIGNAL
Purchase = REVENUE

Roleごとに完了の意味を揃えることで、次工程へ誤った状態が渡りにくくなります。

Escalationを整える

Agentが止まったとき、

「どうしますか？」

だけでは人間の仕事が増えます。

最低限、

Goal
Current State
Blocker
Evidence
Options
Recommended
Human Action
Resume Point

を返させる。

これなら人間はGateだけ越え、AIはそこから再開できます。

FailureはTraceへ変える

失敗をゼロにするのではなく、

Detect → Stop → Preserve → Classify → Rollback → Learn → Resume

の流れを用意します。

同じ失敗が繰り返されないよう、Failure Traceを次のEvalやRegression Testへ変える。

Agentを増やさない

新しいAgentは、同じ欠損が何度も起き、既存Roleでは処理できないことがEvidenceで確認されたときだけ追加します。

「面白そう」「便利そう」は理由にしません。

AIを社員のように扱う本当の意味

人格を付けることではありません。

担当範囲
権限
禁止事項
完了条件
Evidence
Escalation
Stop条件
Outcome

を持たせることです。

完全版のAgent Role Charter、Permission Matrix、Approval Gate、Evidence Contract、Failure / Rollback Protocolは既存noteへ追記しています。

https://note.com/deft_eel6718/n/nfce5ac047c15

Sources

Running Codex safely at OpenAI:
https://openai.com/index/running-codex-safely/

OpenAI Presence:
https://openai.com/index/introducing-openai-presence/

OpenAI Presence Help:
https://help.openai.com/en/articles/20001405

DEV Community: Stratum Praxis

AI codingは速いのに売上が増えない理由 CodexをRevenue Loopへ接続する

BUILDとREVENUEを分ける

GitHubから始めない

Codexへ渡す仕事を変える

新しいものを作らない

GitHubへ戻すのは売上ではなく学習

AIを増やす前に、Revenue Loopを閉じる

Sources

AIで作る前に、Revenueの詰まりを直す 売れないパイプの診断法

Revenueを細かく見る

Impressionはある、Visitがない

Visitはある、CTAがない

CTAはある、Checkoutがない

Checkoutはある、Purchaseがない

LikeやReplyはRevenueではない

新商品を作る前の条件

72時間だけ直す

重要なのは一番Revenueに近い0点

AIを増やす前に、引き継ぎを作る ChatGPT・Claude・Codexを止めないHandoff設計

継続機能があっても、別のAIへ状態が自動移植されるわけではない

会話の要約より「現在状態」を渡す

HandoffだけでなくAcceptanceを作る

GitHubは会話置き場ではなく、実装Evidenceの受け渡し地点にする

役割を増やすより、受け渡しを固定する

実際に使えるテンプレート

Sources

AI社員を増やす前に、権限と停止条件を決める Agent Operating Constitution

Role名より境界を決める

Actionを3段階に分ける

Human Gateを決める

Evidence Contractを作る

Escalationを整える

FailureはTraceへ変える

Agentを増やさない

AIを社員のように扱う本当の意味

Sources

AI codingは速いのに売上が増えない理由 CodexをRevenue Loopへ接続する

BUILDとREVENUEを分ける

GitHubから始めない

Codexへ渡す仕事を変える

新しいものを作らない

GitHubへ戻すのは売上ではなく学習

AIを増やす前に、Revenue Loopを閉じる

Sources

AIで作る前に、Revenueの詰まりを直す 売れないパイプの診断法

Revenueを細かく見る

Impressionはある、Visitがない

Visitはある、CTAがない

CTAはある、Checkoutがない

Checkoutはある、Purchaseがない

LikeやReplyはRevenueではない

新商品を作る前の条件

72時間だけ直す

重要なのは一番Revenueに近い0点

AI Is Not Your Bottleneck. Your Organization Is.

The bottleneck moved downstream

Faster AI makes organizational friction more expensive

Throughput is the missing AI metric

The unit of automation should be the closed loop

Human involvement should be intentional, not inherited

Measurement is part of throughput

The practical throughput test

The next AI advantage is organizational throughput

AIを増やす前に、引き継ぎを作る ChatGPT・Claude・Codexを止めないHandoff設計

継続機能があっても、別のAIへ状態が自動移植されるわけではない

会話の要約より「現在状態」を渡す

HandoffだけでなくAcceptanceを作る

GitHubは会話置き場ではなく、実装Evidenceの受け渡し地点にする

役割を増やすより、受け渡しを固定する

実際に使えるテンプレート

Sources

AI社員を増やす前に、権限と停止条件を決める Agent Operating Constitution

Role名より境界を決める

Actionを3段階に分ける

Human Gateを決める

Evidence Contractを作る

Escalationを整える

FailureはTraceへ変える

Agentを増やさない

AIで作る前に、Revenueの詰まりを直す売れないパイプの診断法

AIで作る前に、Revenueの詰まりを直す売れないパイプの診断法