方法 · AIによるソフトウェア · オープンソース
Urazuke、裏付けの方法。
Urazuke（裏付け）とは、ある主張が持つ根拠、それを背後から支えるもの。プロジェクトのオーナーがコードを一行も読むことなく、堅牢で本番運用可能なソフトウェアを人工知能で構築するための、私の方法です。今日本番稼働している三つの実在するシステムから、昔からのシステム工学と、それらのシステムがモデルの脆い適用箇所について教えてくれたことに依拠して蒸留しました。
著者：Pablo Kuschniroff、Claude Codeの支援による。
Creative Commons BY-SA 4.0 · 八言語 · ツールに対して中立 · 本番稼働中の三つのシステムが出典 · オープンソースで協働的
テーゼ
AIは方法を中断しない。方法を継続する。
テーゼの前に、私にとって大切な断りを。この方法は、痛手のたびに当てたつぎはぎの集まりではありません。二つの要因の組み合わせから生まれました。第一は私自身のシステム工学の知識です。調査、要件、サイジング、証拠としてのテスト、再現可能なデプロイ、監査。これらのモデルが存在するずっと前から持っていたものです。第二は、本番稼働中の三つのシステムがインシデントを重ねて見せてくれたこと。モデルがそれらの原則を脆く適用する箇所、したがって文書で締めるべき箇所です。傷跡は厳密さが必要な場所を証明するのであって、原則の起源ではありません。
業界は二十年前にコードの書き手を信用することをやめました。執筆がジュニア、外注、ローテーションのチームに移ったとき、一行ずつのレビューは維持不可能になり、その代わりに育ったのが今日当然視されるすべてです。自動テスト、継続的インテグレーション、受け入れ基準、緑なしには何も通さないパイプライン。それが「書く者は信用できない」に対するシステム工学の答えでした。コードを読むのではなく、証拠を要求する。モデルは次の書き手であって、初めて疑うべき書き手ではありません。
人間の努力がどこへ行くか
人間は二つのことだけをします。決定し、成果物を検証する。起草、構築、テスト、計測、文書化はモデルがします。各段はコードを読まない完全性の検証で終わります。
証拠は自身を証明する
一度も失敗するのを見ていないテストは、何かを証明しているかわかりません。テストのない計器は嘘をつきます。盲点のない報告は隠しています。品質管理の独立という規律を、一歩内側に持ち込んだものです。
成果物のコスト
かつて文書は高価で古びました。今は再生成が無料なので、ルールは「同じコミットで」「AIなしで手で再現可能」になります。達成不可能な理想だったものがゲートになります。
何であり、何でないか
疲れず、しかし信じることもできない構築者に適用されたシステム工学。
システム畑の人には馴染み深く響きます。調査、要件、サイジング、設計、構築、テスト、デプロイ、運用、監査。バイブコーディング畑の人には持っていないもの、まさに骨格を与えます。
何であるか
- 方法です。何をどの順でするか、モデルに何を頼むか、何を納めてもらうべきか、完全だとどう知るか。
- 四つのフェーズに二十四の段、それぞれに契約があります。文脈、プロンプト、期待される成果物、検証、警告サイン。
- ツールに対して中立。Claude Code、Cursor、Codex CLI、Gemini CLI、Forge。すべての成果物はファイル、テスト、またはスクリプトです。
- 本番稼働中の三つの実在システムから蒸留。すべてのルールはそれを生んだコミットと痛手に結び付いています。
何でないか
- プログラミングやフレームワークのコースではありません。
- モデルにうまく書かせるプロンプトのコツ集ではありません。
- 金曜のデモ用プロトタイプのための方法ではありません。その後も動き続けなければならないもののためです。
- どんなプロジェクトにも使える方法ではありません。第0段が境界を文章で定めます。
はしご
二十四の段、四つの区間、登る順に。
段は登る時系列の順に番号が振られています。立ち上げの段はプロジェクトごとに一度、ループの段は変更のたび、本番リリースの段は最初のデプロイ前に一度、運用の段はシステムが稼働してから。第23段がサイクルを閉じ、0へ戻ります。各段には八部構成のカードとプロンプト付きの契約があります。期限はありません：方法はプロセスであって、速さの約束ではありません。
プロジェクトごとに一度、機能を書く前に
最も飛ばしたくなり、飛ばすと最も高くつく五つ。
変更のたびに、プロジェクト全体を通じて
各保留事項で行う順に並んでいます。最初の二つのブロックで学び、プロジェクト全体で練習します。
最初のデプロイ前に一度
「動く」を「持続できる」に変える：監査、ロック、本番への経路、可観測性、永続化、脆弱性、性能、マニュアル。
システムが稼働してから
周期レポート付きの二つの監視、常駐エージェント、そしてサイクルを閉じて0へ戻るレトロスペクティブ。
どんなプロジェクトでも譲れない十三の段
- 適格性（一時間。数か月を節約）
- 共働の約束
- 「何でないか」を含む短い定義
- 事業の数字でサイジング
- 計画としての保留項目
- オーナーと日付付きの決定
- 赤で見たテスト
- 検証済み / 信じている / 盲点の報告
- 数字で語るレトロスペクティブ
- パイプラインでの依存関係と秘密情報のスキャン
- エラーの集中捕捉とレポート
- パイプラインでのコード品質、最低限
- 人が実行する手動テストケース
タイムライン
各段をいつ登るか、そしてその間に何が起きるか。
タイムラインのない方法は、善意のリストにすぎません。これはどんなプロジェクトにも当てはまるタイムラインです：五つのフェーズを順に、各フェーズで段のほかにすること：要件の取り込み、インフラ、統合とデプロイのパイプライン、開発、エンドツーエンドテスト、人の目、人のテスト。期限なし：各フェーズはシステムが求めるだけ続きます。
取り込み
要件工学の古典的な方法によるオーナーとの調査。インタビュー、ユースケース、状態を持つドメインモデル、画面プロトタイプ。散文で、意図的に不完全に。エージェントが質問して補完します。
立ち上げ（第0〜4段）
適格性、約束、意味ツリーを含む定義、サイジング。そして初期インフラのすべてとCI/CDチェーン。リポジトリ、テスト環境、継続的インテグレーション、空のシステムの最初のデプロイ。オーナーがURLを開いて空の画面を見ます。
ループ（第5〜12段）
機能ブロックごとに。各保留項目で、仕様、決定、赤で見たテスト、フローのエンドツーエンドテスト、オーナーが見るスクリーンショット。各ブロックの締めで、完全なエンドツーエンドのテスト群とテスト環境での人間によるテスト。
本番リリース（13〜20）
別セッションによる監査。請求や送信をするものを作る前の錠。試されたロールバック付きの本番へのチェーンの完成。三つのマニュアル。すべてのフローに対するオーナーの受け入れテスト。 さらにデプロイ前の運用品質の四段：可観測性、永続化、脆弱性、性能。
運用（21〜23、そしてループ）
人の名で動く常駐エージェント。定期監査。すべての進化は完全なループから入りデプロイチェーンから出ます。各段階の締めに数字による振り返り。 二つの監視（リソースとエラー）は最初のデプロイの週に組み込み、オーナーが読む周期レポートを出す。
エンドツーエンドテストは最後に一度ではない
各保留項目で、それが触れたフロー。各ブロックの締めで、存在するすべてのフロー。本番前に、昇格する正確なバージョンですべてのフロー。三番目だけやれば、何週間も未テストのまま終わりに着きます。
三つのユースケース
空のフォルダか、方法で作られたシステムか、引き継いだシステムか：どこから入るか。
はしごは空のフォルダを見て書かれています。学ぶには最も明快ですが、最も多いケースではありません。エージェントを開く前に、自分が三つのうちどのケースにいるかを知っておくべきです。入口が変わるからです。そして三つ目、すでに存在し、この方法で生まれなかったシステムには独自の道があります：書き直さずに正常化し、そのあとではじめてはしごを登ります。
新規プロジェクト
空のフォルダと、依頼を持つオーナー。第0段から入り、二十四段を順に登ります：最初の機能の前に一週間の立ち上げ。主文書、契約、コースが記述しているのはこれです。
方法ありの進化・是正
システムはすでにはしごを登っています：約束、地図、証拠付きで閉じた保留事項、テスト一式、デプロイ、マニュアルがあります。第5段から入ってブロックを開き、ループに従います。第15段が第0段に戻るのです。
方法なしの進化・是正
利用者がいて稼働中の、他人か、あるいは証拠なしに自分で作ったシステム。八つの正常化ステーション（N0〜N7）：誰も書かなかった入力を自動発見で出所マーク付きに復元し、安全ベルトを厳格なゲートにし、負債はモジュールに触れるたびに返します。そのあと、是正モードか進化モードのループへ。
各段の契約
どう頼み、何が返ってくるべきで、完全に返ってきたとどう知るか。
各段は五節の契約で実行されます。モデルへのプロンプトは英語で、文書の八つの版で同一の単一の原本。各プロンプトの下に、何を求めているか、なぜ各条項があるかの説明が読者の言語であります。
必要な文脈
一般的な名前で。調査は本質的に不完全です。フォームで補完するのではなく、モデルが質問して補完します。
プロンプト
原文で。すべて同じ条項を持ちます。モデルは文脈が十分か評価し、進む前に足りないものを求め、事業だけが持つデータを推定も発明もしない。
期待される成果物
成果物の詳細な特徴。どのファイル、どの節、何が欠けてはならないか。
完全性の検証
オーナーがコードを読まずに成果物に対して行う検査。一つでも「否」なら段は登れていません。
警告サイン
登ったように見えても段を登り損ねた症状。数週間後、既に痛む頃に見えるものです。
プロンプトの例 · 第7段
docs/PENDING.md にある「前提・操作・結果」の受け入れ基準と「どう検証するか」付き）、すでに実装済みの変更、docs/STATUS.md にあるテスト一式のコマンド、そして対象フローのデータが入った稼働中のテスト環境。ドキュメントでは、すべてのプロンプトの前にこのようなブロックがあります：あなたがどのファイルを、どんな内容で作るのか、そして最低限受け入れられる状態は何か。なぜ英語か。同じ内容が他言語では30〜50%多くのトークンを占め、モデルは英語でより正確に指示に従い、業界の語彙は英語だからです。しかし英語を障壁にはしたくありません。文書では各プロンプトに文書の言語への翻訳と、このようなボタンが付いています。モデルに貼るのは英語。翻訳はあなたが理解するためのものです。すべて「Reply in my language」で終わります。
要件から保留項目へ
昔からの要件工学を、モデルが構築でき、あなたが検証できる単位に分解する。
要件とはチャットの中の顧客の一文ではありません。数十年前から存在し、頼めばモデルがとてもうまく、頼まなければとてもまずく適用する方法で処理されたその一文です。インタビュー、ユースケース、ドメインモデル、受け入れ基準、画面プロトタイプ、トレーサビリティ。この方法では三つの成果物がそれらを支えます。
意味ツリー
ツリーとしてのシステム。ドメイン、その下にアクター、プロセス（ユースケース）、状態を持つエンティティ、画面、連携。各ノードには保留項目と決定がぶら下がります。エージェントが構築し、あなたが修正し、エージェントがコードに触れる前に読むものです。どのノードにもぶら下がらない保留項目はスコープ外で、十秒で分かります。
詳細仕様は各保留項目の中に生きる
古びていた長い仕様書は分解されます。各保留項目はツリーのノード、顧客の言葉による元のストーリー、説明、決定と日付付きの業務ルール、データ、画面、エッジケース、受け入れ基準、検証方法を持ちます。その仕様を読むことが、コードを読むことに最も近く、それが正しい距離です。
閉じた保留項目はドキュメントである
閉じた保留項目は削除されません。仕様、それを生んだ決定、閉じた証拠、コミット、日付とともに残ります。閉じた保留項目のキューはシステムの機能履歴であり、そこから変更履歴、ユーザーマニュアル、そして半年後の「なぜシステムはこうするのか」への答えが生まれます。
どんなツールでも
成果物はファイル、テスト、スクリプト。変わるのはどこに置くかだけ。
Claude Code
約束とルーチンはプロジェクトのCLAUDE.mdに。段のプロンプトは各段を登るときチャットに貼ります。
Cursor
ルーチンは常に有効なルールとして.cursor/rules/に。残りは同じ。
Codex CLI / Gemini CLI
リポジトリのルートのAGENTS.mdまたはGEMINI.mdに。
Yujin Forge
約束とルーチンは教義であり、プロンプトは各ゲートを通過するとき自動で注入され、保留項目の記録はネイティブです。コピー＆ペーストの少ない同じ方法。Forgeを知る →
コース
実践課題付きの二十四のレッスン、アプリケーションが本番に出るまで。
段ごとに一レッスンのコース形式マニュアル。自分のプロジェクトか、ガイドプロジェクト（「Turnera」、リマインダー、手付金、個人データを持つ予約表。どの段も偽物にならないために必要なすべて）に方法を適用します。本番リリースのチェックリストで終わります。オーナーがコードを開かずに検証する二十四の条件。 コース第2部は同じ診療所を引き継いだシステム（「引き継いだTurnera」）で扱い、修正し進化させる前に正常化する方法を教えます。
理解すべきこと
各段の概念を、人に説明するように、それを生んだ実際の失敗とともに説明。
課題、一歩ずつ
エージェントへの正確なプロンプトと、返ってきたものをどうするか。わざとのテストも含みます。質問に答えず、何をするか見る。
検証と提出物
納められたものについてコードを開かずに自問する質問と、最後に存在しなければならないファイルまたは証拠。
よくある間違いとガイドプロジェクト
初回にほぼ全員に起きることと、各レッスンをTurneraに適用するとどう見えるか。
これから入る人へ
手でプログラミングする時代の後のジュニア開発者。
モデルがコードを書くなら、ジュニアはどう学び、何を学び、何になるのか。比重が下がる育成の焦点、上がる焦点、なお必須のリテラシー、目的、そしてメンター付きの十二週間計画についての別文書。方法全体と同じく、初心者向けに書いています。
チームで
複数の開発者が、それぞれのエージェントと、一つの共有ブランチで。
方法は単数形で書かれています。この文書は複数人のときどう適用するかを述べます：共有ブランチの七つのルール（保留事項を所有の単位に、小さく頻繁に統合、CIを審判に、未完成はスイッチの後ろに、地図を衝突検知器に、名前付きの決定、コードではなく証拠を見る）、段の分担、そしてプロンプト。
すべての資料、八言語で
あなたの言語で読む。
スペイン語が正本で、他の七つの版は翻訳です。食い違えばスペイン語が優先されます。プロンプトはすべてで同一です。言語ごとに三つの文書。主文書（テーゼ、三つのシステムの調査、二十四の段、実際の失敗、用語集）、二十四の契約、コースマニュアル。 そして第5版からは、各言語に二つの文書が加わります：すでに存在するシステムのための進化・是正の道と、引き継いだガイドプロジェクトを扱うコース第2部です。
この方法はCreative Commons 表示 - 継承 4.0で公開されています。帰属表示と同一ライセンスのもとで、利用、翻訳、改変ができます。リポジトリは公開で協働的です：github.com/pkuschnirof/urazuke。改善はフォークからのプルリクエストとして証拠とともに提出され、私がレビュー後にマージします。
これは別の名前ですでに存在するのか？ 2026年10月までに似たものが何あるか（Uncle Bobと彼の「gauntlet」、Tsumiki、Spec Kit、Consort、IACDM、Osmaniほか）、主張するより引用すべきもの、どこにも見つからなかったもの、そして最も深刻な反論とその答えを徹底的に調べました。主文書のパートF「関連する取り組み」にあります。
Forge での実行マニュアル二冊。実際の練習プロジェクトで作った、スクリーンショット付きの手順書です：新規プロジェクト（Turnera）と既存プロジェクト（引き継いだ Turnera）。各段で集めた証拠つき（スペイン語）。
翻訳対象の文書群の外にある、もう二つの文書：ゲートの解説（英語。ツールの文書であり、データから生成されるため）と、本手法に対するAIモデルによる評価（スペイン語）。
ツールから本手法を利用するなら、リポジトリを読む必要はありません。データインターフェースは yujin.app/urazuke/api/ にあります。その索引は、各リソースの正規アドレス、バージョン、ハッシュを列挙します：gates.json（ゲートの機械可読な定義）と prompts.json（プロンプト）。ハッシュは内容から再計算できるため、古い複製はおのずと判明します。
出自
本番稼働中の三つのシステムと、日付と証拠付きで文書化された四二十四の事例。
今日実際の人々が使う本番稼働中の三つのリポジトリを読み取り専用で調査しました。方法が形になったツール（五か月で1,090コミット）、金銭と機微なデータが関わる医療機関向けの自動化システム（641の保留項目、すべて閉じられた）、市民団体のオムニチャネル窓口（計測が体系的に構築に先行した最初のもの）。方法で引用する各事例は参考資料文書に番号付きで記されており、手順はきれいなまま、詳細はクリック一つ先にあります。顧客は匿名化され、数字、日付、コミットは実在のものです。
モデルが当たり前のことの適用に失敗する場所
二度嘘をついた計器。成功と報告された認証エラー。四つのうち三つが間違っていた主張。それぞれが、私にとって当たり前の原則がプロンプトの明示的な条項にならねばならない場所を教えてくれました。
数字による振り返り
60ドルと73分対90分で、エージェントのチームを丸ごと廃止しました。16〜27分対11分で、デプロイを分割しました。はしご自体がそれです。
Pablo Kuschniroff、Claude Codeの支援による
RPAForce / Yujin。方法は自身に適用されます。その決定は日付と原文の言葉で記録され、リポジトリは2026年10月18日からgithub.com/pkuschnirof/urazukeで公開されています。
よくある質問
よくある質問。
- プログラミングを知っている必要がありますか？
- いいえ。判断力と決定する時間を持つドメインのオーナーと、リポジトリ、コミット、プッシュが何かの最低限の知識が必要です。方法はまさに、オーナーがコードを読む代わりに証拠を検証するために存在します。
- どんなプロジェクトにも使えますか？
- いいえ、そしてそれは欠陥ではありません。二つの排除条件があります。証拠を残す標準リポジトリと、エンドツーエンドでテストするためプログラムから操作できる画面。第0段が境界を文章にします。
- ForgeやNAC3が必要ですか？
- いいえ。方法はツールに対して中立で、すべての成果物はファイル、テスト、スクリプトです。Forgeはゲートとプロンプト注入を自動化しますが、段はForgeなしに存在します。NAC3は今日画面のテスト可能性を達成する手段であって、条件ではありません。
- 文書が私の言語なのに、なぜプロンプトは英語なのですか？
- モデルは英語でより正確に、より少ないトークンで指示に従うからです。各プロンプトは八つの版で同一の単一の原本で、その下にあなたの言語で説明され、「Reply in my language」で終わります。
- 小さいプロジェクトは端から端までどれくらいかかりますか？
- あえて期限は示しません。この方法は、コードを一ビットも理解せずに運用・保守できるシステムを作るためのプロセスであって、速く作るためのプロセスではありません。速さは結果として現れることがあるだけです。方法が決めるのは順序とゲート。各段階にかかる時間は、あなたのシステムの規模と複雑さが決めます。
- 改善を提案するには？
- 証拠とともに。第15段は、各振り返りがそれを正当化するインシデント付きのはしごへの具体的な変更提案で終わることを求めます。提案はgithub.com/pkuschnirof/urazukeのフォークからのプルリクエストとして提出され、私がマージ前にレビューします。