DEV Community: Stratum Praxis

A 12-point pre-renewal check for AI and SaaS spend

Stratum Praxis — Sun, 27 Sep 2026 05:23:20 +0000

A 12-point pre-renewal check for AI and SaaS spend

Software is easy to add and surprisingly hard to remove. Before another AI or SaaS subscription renews by inertia, force each tool through a short decision check.

The 12 questions

Owner — Is one person accountable for both value and renewal?
Workflow — Can the job this tool performs be explained in one sentence?
30-day removal — What actually breaks if the tool disappears for a month?
Overlap — Is another paid product already covering the same capability?
Seat sizing — Does paid capacity match real usage?
AI premium — Is the higher AI tier producing measurable value?
Break-even — Is there a rough economic case for keeping it?
Frequency — Is the tool used often enough to justify a subscription?
Renewal visibility — Are the renewal date, notice period and owner known?
Fallback — Can the workflow continue if the tool is removed?
Data risk — Are permissions and sensitive-data exposure understood?
Decision — Has someone explicitly chosen what happens next?

End with one of five decisions

The goal is not "cut software." The goal is to stop default renewal.

KEEP — the value is clear.
REDUCE — the plan or seat count is oversized.
CONSOLIDATE — capability overlaps with another paid tool.
REVIEW — the evidence is too weak to decide yet.
CANCEL — the cost no longer has a defensible role.

A stack becomes expensive not only because individual tools cost too much, but because nobody owns the decision to keep, resize, combine or remove them.

The free interactive version of this checklist is available at Stratum Praxis:

https://stratumpraxis.com/ai-saas-spend-audit-checklist.html?utm_source=devto&utm_medium=article&utm_campaign=renewal_check

Choosing an AI App Builder for iPhone: The 7 Questions to Answer Before You Build

Stratum Praxis — Fri, 25 Sep 2026 04:54:45 +0000

AI app builders have made the first hour of app creation dramatically easier.

That creates a new problem for non-technical founders: a convincing prototype can appear long before you know whether the build path fits the real product.

The important question is not:

Which builder can generate the nicest first screen?

It is:

Which build path can survive the requirements that appear after the first screen?

If you want to release a real iPhone app, use these seven questions before you commit the rest of the project.

1. What are you actually shipping?

Write the release target in one sentence.

Examples:

a clickable prototype for user interviews;
a web product that also needs a mobile shell;
a production mobile app with accounts and backend data;
an app with payments, notifications or device-specific behavior.

These are different jobs.

A builder can be excellent for validation and still be the wrong long-term production path. That does not make the tool bad. It means the tool and the job are different.

2. How will you test the hard parts?

Do not test only the easiest screen.

Pick the requirement most likely to break your plan and prove that first.

That might be:

authentication;
a payment flow;
notifications;
a third-party integration;
offline behavior;
a multi-step onboarding flow;
data synchronization;
device-specific behavior.

A fast prototype is useful. A fast prototype of the wrong risk can waste time.

3. Is the release path clear?

“Builds mobile apps” is not the same statement as “I understand how this project reaches a production release.”

Before you invest deeply, understand the path from your current project to:

device testing;
release configuration;
store submission;
review changes;
resubmission;
later updates.

You do not need to become a release engineer. You do need to know whether the path exists and whether it fits your skills and budget.

4. Which operational features are required for v1?

Make a short list and separate it into:

Must have now

required for the first real user to receive the promised value.

Later

valuable, but not required to validate the product.

Optional

useful only if the core product works.

This prevents a long feature checklist from hiding one critical blocker.

For many apps, the decision changes when you add accounts, payments, notifications, backend data or unusual integrations.

5. What happens if you outgrow the builder?

This question is easy to ignore when the tool feels fast.

Ask what you actually own or can transfer:

source code;
project files;
backend data;
deployment configuration;
integrations;
design assets;
domain and account ownership.

Then ask a harder question:

If I hire an engineer six months from now, what can I hand them?

Migration risk is part of product cost even when it is invisible on the pricing page.

6. How will iteration work after launch?

The first release is not the finish line.

Consider the operating loop:

feedback → bug report → diagnosis → fix → test → release → repeat.

The right builder is not just the one that helps you create version 1. It should fit the way you expect to maintain version 1.1, 1.2 and beyond.

7. When should a human engineer enter the loop?

AI-assisted building does not require you to avoid engineers forever.

A useful plan defines the handoff condition in advance.

Examples:

the app needs complex native behavior;
a production bug cannot be reproduced reliably;
security-sensitive flows become material;
an integration is outside the builder's supported path;
performance or maintainability becomes a real constraint.

This keeps engineering help as a targeted escalation instead of an emergency rescue.

A simple elimination method

If you are comparing several AI app builders, use this sequence:

Describe the app you must release, not the app you can demo.
Mark every requirement as v1, later, or optional.
Eliminate any build path whose v1 release capability is unclear.
Prototype the hardest v1 requirement first.
Only then compare price, interface quality and generation speed.

The goal is not to find a universal winner.

The goal is to reduce the chance that you discover the wrong constraint after you have already built most of the app.

Need a structured comparison?

I made a short fit-check page for this exact decision:

AI App Builder for iPhone in 2026 — 7-Point Fit Check

If your problem is already “I have several builders in front of me and need to choose based on my use case and constraints,” the existing AI App Builder Router 2026 is also available from that page.

Stratum Praxis does not rank vendors in this guide. Builder capabilities change, so verify current provider documentation and platform requirements before committing to a production release.

AIエージェントを「組織」として動かす方法 AIを増やしても仕事が減らない理由

Stratum Praxis — Wed, 16 Sep 2026 02:59:45 +0000

AIを使えば使うほど、なぜか人間の仕事が増えていないでしょうか。

ChatGPTに調査させる。
Claudeに整理させる。
別のAIに文章を書かせる。
さらに別のAIにチェックさせる。

そして最後に、人間が結果をコピーして、別のAIへ貼り付ける。
説明し直す。
前提を補足する。
間違いを修正する。

便利になっているはずなのに、気づけば人間がAIたちの中間管理職になっています。

この問題は、モデル性能だけでは説明できません。

本質は、AI同士が組織として働くための設計がないことです。

AIを10体使っても「10人のチーム」にはならない

AIエージェントを複数配置する仕組みが増えています。

しかしAIを10体作っても、それぞれが好き勝手に調査し、好き勝手に判断し、好き勝手に成果物を作れば、それは組織ではありません。

ただの10個のチャット画面です。

人間の会社でも、優秀な人を大量に採用しただけでは強い組織にはなりません。

必要なのは、

誰が何を担当するのか
何をもって完了とするのか
何を根拠として次へ渡すのか
誰が検証するのか
どこで人間が承認するのか

という仕事の構造です。

AIでも同じです。

最も壊れやすいのは「引き継ぎ」

複数AIを使うと、1体ごとの性能以上に重要になるものがあります。

Handoff──仕事の引き継ぎです。

例えば調査AIが、

最近、このテーマへの言及が増えている。ただし購入需要まで確認できていない。

と判断したとします。

次のAIへ、

この市場は伸びています。

とだけ渡ったらどうなるでしょう。

さらに次のAIが、

成長市場なので商品を作るべきです。

と解釈する可能性があります。

最初は「言及が増えた」だけだったのに、引き継ぎを重ねるうちに「市場が伸びている」、最後には「売れる」へ変わってしまう。

誰も意図的に嘘をついていません。

事実と解釈が、引き継ぎの途中で混ざっただけです。

だからAI組織では、会話そのものよりも、状態・Evidence・未確認事項を構造化して渡す必要があります。

「役職」を付けるだけでも足りない

リサーチ担当。
ライター。
営業担当。
監査担当。

こうした名前をAIへ付けるだけでは、組織にはなりません。

重要なのは役職名ではなく、結果責任です。

例えば「リサーチ担当です」では曖昧です。

より強い定義は、

公開情報から今動く価値がある市場変化を発見し、確認済みEvidenceと未確認事項を分離した状態で次担当へ渡す。

です。

仕事の名前ではなく、次の担当が安全に動ける状態まで責任を持たせます。

AI組織に必要な7つの設計

最低限、次の7つを決めるだけでも運用はかなり変わります。

1. 担当

誰がその仕事を所有するのか。

2. 結果責任

何が起きたら、その仕事は完了なのか。

3. Evidence

何を根拠として次工程へ渡すのか。

4. Current State

現在どこまで進んでいるのか。

5. Next State

次に何を1段だけ進めるのか。

6. Audit

誰が事実・論理・品質の異常を止めるのか。

7. Human Approval

AIだけで実行してよい範囲と、人間判断へ戻す境界はどこか。

この7つが揃うと、AIは「質問に答えるチャット」から、少しずつ仕事を所有する担当へ変わります。

AI同士は長文で会話しなくてもいい

AI AからAI Bへ仕事を渡すたびに、過去の会話全文を読ませる必要はありません。

次担当が本当に必要なのは、

今回の目的
現在状態
確認済みEvidence
解釈
未確認事項
リスク
次に変えたい状態
次担当へ要求する成果

です。

つまり、AI間では「自然な会話」よりも構造化されたHandoffの方が重要になる場面があります。

ただし、人間が読めない謎の内部言語にしてしまうのも危険です。

監査できなくなるからです。

理想は、機械が処理しやすく、人間も必要なとき確認できる中間形式です。

監査AIには「感想」を言わせない

制作AIとは別に監査AIを置いても、

この文章を評価してください。

と頼むだけでは弱いままです。

「非常に分かりやすいです」「よく整理されています」のような感想が返りやすいからです。

監査担当には先にFailure条件を与えます。

例えば記事なら、

根拠のない断定
タイトルの約束を本文で回収していない
Evidenceと解釈が混ざっている
一般論だけで独自性がない
無料検索で得られる情報しかない
CTAと本文の目的が一致していない

などです。

監査担当の仕事は褒めることではありません。

出してはいけない理由を見つけることです。

「完全自律」より承認境界を設計する

AIエージェントという言葉から、「人間を完全に外すこと」が目標だと考えがちです。

でも実務では、そこまで自動化する必要はありません。

公開情報の収集、比較、内部分析、下書き、重複確認などはAIへ任せやすい。

一方で、支払い、契約、重要な顧客連絡、大きな公開判断、取り消しにくい変更などは人間承認を残せます。

重要なのは人間をゼロにすることではありません。

人間が毎回すべてを仲介する状態をなくすことです。

AI同士で安全に流せる仕事は流し、価値判断や例外だけ人間へ戻す。

その方が組織として扱いやすくなります。

AIの数ではなく「仕事が流れるか」で評価する

記事制作なら、

市場Signal
↓
需要確認
↓
構成
↓
執筆
↓
Fact Check
↓
品質監査
↓
公開
↓
読者反応
↓
購入
↓
Learning

という流れがあります。

営業なら、見込み客発見から接触、返信、提案、Checkout、Paymentまで別の流れがあります。

AI組織の評価基準は「何体のAgentを持っているか」ではありません。

仕事が途中で止まらず、事実を変質させず、最終結果まで流れるか。

ここを見るべきです。

実装テンプレートまで含めた完全版

この考え方を実際に組むための完全版では、

1担当1結果責任の設計
担当を分離する5つの基準
AI間Handoffテンプレート
EvidenceとInterpretationを分離する方法
Current State → Next State管理
監査AIのFailure条件
事実・論理・成果の3段階監査
GREEN / YELLOW / REDの人間承認境界
成功・失敗を次回へ残すLearningテンプレート
最小4担当で始めるAI組織
Revenueまで接続する設計

まで、コピーして使える形式にしています。

有料完全版はこちら：

https://note.com/deft_eel6718/n/n98b41d9785fa?app_launch=false

AIを増やす前に、まず1本の仕事を最後まで安全に流せる構造を作る。

そこから必要な担当だけ増やす方が、複数AIはずっと強くなります。

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

Stratum Praxis — Sun, 13 Sep 2026 09:42:05 +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 and SaaS Renewal Checklist: 12 Questions Before You Pay Again

Stratum Praxis — Sun, 13 Sep 2026 09:41:29 +0000

AI and SaaS stacks rarely become expensive because of one obviously bad purchase. The bigger problem is renewal inertia: subscriptions remain active after ownership changes, usage falls, features overlap, or a higher tier stops earning its premium.

Before the next renewal, make every recurring software cost answer a small set of questions.

1. Who owns the outcome?

A tool without a clear owner can keep renewing without anyone being responsible for its value. Name one person who owns both the workflow result and the renewal decision.

2. What job does the tool perform?

Describe the job in one sentence. If the answer is only “we use it for AI” or “the team likes it,” the value is not yet specific enough to defend.

3. What breaks if it disappears for 30 days?

This question separates convenience from operational dependence. If nothing material changes, the subscription deserves a closer look.

4. Is another paid tool doing the same job?

Overlap often hides across writing, meeting notes, automation, analytics, search, support, design, and AI-assistant products. Review capability, not just product names.

5. Are seats and plans right-sized?

A useful product can still be oversized. Check inactive seats, premium tiers, unused add-ons, and capacity that no longer matches real demand.

6. Does the AI premium have measurable value?

If an AI tier costs more, identify what the premium changes: time saved, throughput, quality, conversion, risk reduction, or another measurable outcome.

7. Can you explain the rough break-even point?

The calculation does not need to be perfect. It needs to be visible enough to compare recurring cost with workflow value.

8. Is the product used often enough to justify subscription pricing?

Low-frequency use may be better served by a smaller plan, usage-based pricing, consolidation, or removal.

9. Are the renewal date and notice period visible?

A decision made after the cancellation window closes is not a decision. Record the renewal date, notice period, contract owner, and next review date.

10. Is there a fallback?

Know how the workflow continues if the product disappears. A fallback makes cancellation and negotiation decisions safer.

11. Are permissions and data exposure understood?

Software value does not cancel out governance risk. Review access, sensitive data, integrations, and what happens to information when the subscription changes.

12. Has someone made an explicit decision?

Every relevant subscription should end in one of five states:

KEEP — value is clear.
REDUCE — seats or tier are too large.
CONSOLIDATE — another paid product covers the same capability.
REVIEW — evidence is not strong enough yet.
CANCEL — the cost no longer has a defensible role.

The goal is not to cut software indiscriminately. The goal is to replace silent auto-renewal with an explicit decision.

Run the free 12-point check

Stratum Praxis has a compact browser-based version of this review. Start there before paying for deeper analysis:

Open the free AI & SaaS Spend Audit Checklist

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

Stratum Praxis — Sun, 13 Sep 2026 09:41:28 +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 09:40:44 +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 09:40:43 +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 — 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を増やした後に、人間側の仕事が減らないことがあります。

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

個々の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 — 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

DEV Community: Stratum Praxis

A 12-point pre-renewal check for AI and SaaS spend

A 12-point pre-renewal check for AI and SaaS spend

The 12 questions

End with one of five decisions

Choosing an AI App Builder for iPhone: The 7 Questions to Answer Before You Build

1. What are you actually shipping?

2. How will you test the hard parts?

3. Is the release path clear?

4. Which operational features are required for v1?

5. What happens if you outgrow the builder?

6. How will iteration work after launch?

7. When should a human engineer enter the loop?

A simple elimination method

Need a structured comparison?

AIエージェントを「組織」として動かす方法 AIを増やしても仕事が減らない理由

AIを10体使っても「10人のチーム」にはならない

最も壊れやすいのは「引き継ぎ」

「役職」を付けるだけでも足りない

AI組織に必要な7つの設計

1. 担当

2. 結果責任

3. Evidence

4. Current State

5. Next State

6. Audit

7. Human Approval

AI同士は長文で会話しなくてもいい

監査AIには「感想」を言わせない

「完全自律」より承認境界を設計する

AIの数ではなく「仕事が流れるか」で評価する

実装テンプレートまで含めた完全版

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

BUILDとREVENUEを分ける

GitHubから始めない

Codexへ渡す仕事を変える

新しいものを作らない

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

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

Sources

AI and SaaS Renewal Checklist: 12 Questions Before You Pay Again

1. Who owns the outcome?

2. What job does the tool perform?

3. What breaks if it disappears for 30 days?

4. Is another paid tool doing the same job?

5. Are seats and plans right-sized?

6. Does the AI premium have measurable value?

7. Can you explain the rough break-even point?

8. Is the product used often enough to justify subscription pricing?

9. Are the renewal date and notice period visible?

10. Is there a fallback?

11. Are permissions and data exposure understood?

12. Has someone made an explicit decision?

Run the free 12-point check

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で作る前に、Revenueの詰まりを直す売れないパイプの診断法

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