調査4結果: 4スキル構成の機能不全分析

1. 4スキル構成の設計思想

4スキル構成（kickoff/planning/execution/completion）は2026年2月21日に確立した。設計上の核心的な目的は「段階的コンテキスト注入」であり、30分〜1時間の長いサイクルを通じて、各フェーズで必要な指示だけをエージェントのコンテキストに載せる仕組みだ。

設計思想の主要ポイント:

kickoff: 状態確認・メモトリアージ・作業選択・サイクルドキュメント作成
planning: researcher（調査）→ planner（計画）→ reviewer（計画レビュー）
execution: builder（実装）→ reviewer（実装レビュー）、通過まで繰り返す
completion: 厳格なチェックリスト検証（「例外は一切認めません」）

この構成が機能する前提条件は「成果物が実装可能な単位に分割されていること」だった。つまり、タスクが具体的なファイル変更・機能追加として表現できるものであり、plannerが計画を立て、builderが実装し、reviewerが成果物を評価できる形である必要があった。

2. 4スキル構成がうまく機能していた時期のサイクル所要時間

cycle-55〜63の所要時間を計測した:

サイクル	内容	所要時間
cycle-55	チートシート追加	89分（20:56〜22:25）
cycle-56	（内容不明）	39分（22:45〜23:24）
cycle-57	SEOメタデータ改善・JSON-LD対策	100分（23:37〜01:17）
cycle-58	チートシート追加・日付ツール改善	234分（08:05〜11:58）
cycle-59	sitemap修正・Markdownサニタイズ・Cron改善	144分（12:25〜14:49）
cycle-60	Mermaidバリデーションテスト整備	134分（15:20〜17:35）
cycle-61	ゴミファイル削除・静的化	266分（18:34〜23:00）
cycle-62	ブログ記事書き直し	68分（23:29〜00:37）
cycle-63	Feed静的生成・バンドル回帰テスト	87分（08:21〜09:48）

典型的な所要時間: 39〜134分。大規模タスク（cycle-58, cycle-61）でも4時間程度。

比較:

cycle-64（分析フェーズ）: 251分（10:22〜14:33）
cycle-65（戦略策定フェーズ1）: 272分（15:20〜19:52）
cycle-66（戦略策定フェーズ2やり直し）: 32時間超（2026-03-04 09:45〜2026-03-05 17:52）

cycle-66は典型的なサイクルの14〜50倍の所要時間となった。

3. cycle-65〜66での問題点

3-1. 通常よりどれだけ長くなったか

通常サイクル（実装系）: 39〜134分（中央値約100分）
cycle-64（フェーズ1分析）: 251分（約4時間）— 典型の2〜6倍
cycle-65（フェーズ2戦略）: 272分（約4.5時間）— cycle-66のやり直しに繋がったため実質「失敗」
cycle-66（フェーズ2やり直し）: 約32時間— 典型の約20倍

cycle-65は「完了」したが、ownerフィードバック（19cb64bbec8）により全面やり直しとなったため、実質的に無駄になった時間を含めると cycle-65+66 の合計は約36時間超。

3-2. マーケティング分析・コンセプト策定が4スキル構成に合わなかった理由

4スキル構成の設計前提と、コンセプト策定作業の本質が根本的に異なっていた。

構造的不適合の3つの軸:

成果物の「正解」が不明確 実装タスクでは「コードが動くか」「テストが通るか」という客観的検証基準がある。しかしコンセプト策定では「このコンセプトが良いか」の判断基準自体をまず構築しなければならない。reviewerが評価できる明確な基準がないため、レビューループが機能しない。
フェーズ間の依存が密結合すぎる 実装タスクは「調査→計画→実装→レビュー」で比較的独立して進められる。しかしコンセプト策定では「どんなコンテンツを作れるか（what）」「何が求められているか（demand）」「競合はいるか（competition）」「実現可能か（feasibility）」のすべてが同時に絡み合い、一方向の流れにならない。ownerが指摘したように「コンセプトレベルで交差点を探るのは難しい」が、その難しさがplannerの計画能力を超えていた。
反復回数が予測不能 実装タスクはレビューで2〜3回のループが典型的だった。しかしコンセプト策定では正解への道筋が不明確なため、「通過」基準に達するまでの反復回数が無制限になりうる。cycle-66ではPhase Fのやり直しだけで2回のowner停止指示と、10件以上のメモの無効化が発生した。

3-3. plannerとbuilderの役割分担がうまくいかなかった点

plannerの問題:

plannerは「計画を立てる」エージェントとして設計されており、実装計画（何のファイルをどう変更するか）には適している。しかしコンセプト策定における「戦略的判断」は、plannerの役割を超えていた。

cycle-65では、plannerがコンセプト案を策定する役割を担ったが、「何を調査したか（researcher）」から「何を作るか（planner/PM）」へのジャンプが大きすぎた。コンセプト策定には本来、ownerレベルの価値判断が必要だったが、それがplannerに委任されてしまった。

cycle-66では、このズレを部分的に補うためPMが強制発想法（4軸×1728組み合わせ）を設計するなど、本来のplannerの役割外の作業をPM自身が行わざるを得なかった。つまり「plannerに委任できる粒度」まで作業を分解するためにPMが大量のコンテキスト管理作業をしなければならず、4スキル構成の「PMはメタ判断に集中できる」という利点が消えた。

builderの問題:

cycle-65〜66の主要成果物（site-concept.md, content-strategy.md）はMarkdownドキュメントの作成であり、コード変更ではない。builderは「実装する」エージェントとして設計されているが、「戦略文書を書く」という作業はbuilderよりもplannerやresearcherの能力の方が適していた。結果として、builderが戦略文書を「実装」するという奇妙な役割分担が生じた。

3-4. reviewerが価値の評価ではなく瑣末な確認に終始した問題

ownerメモ 19cb64bbec8 の指摘を原文から引く:

「メモのやり取りを見ていると、各ステップのレビューが『数字が正しいか』『URLは合っているか』などの瑣末な部分に終始してしまっているように見えます。レビューで一番大事なのは、その成果物が本当に価値のあるものになっているか確かめることです。」

この問題の構造的原因:

reviewer指示の汎用性の問題: reviewerは「成果物をレビューせよ」という汎用指示で動くが、コンセプト文書のレビューに必要なのは「このコンセプトで本当に価値あるサイトが作れるか」という判断だった。しかし reviewerのコンテキストにはこの判断のための情報（市場調査データ、競合分析、技術制約）が十分に入っていなかった。
「承認」のハードルの設定ミス: 実装タスクのレビューでは「コードが動くか」「品質基準を満たすか」という明確な合格基準がある。コンセプト文書では合格基準が曖昧なため、reviewerは確認しやすい「事実の正確性」に逃げてしまった。
バイアスの共有: cycle-66 Phase Fで発生したように、plannerとreviewerが同じ情報（既存サイトコンセプト、既存ターゲット設定）を持っていたため、reviewerはplannerのバイアスを検出できなかった。同じバイアスを持つreviewerは事実上reviewの役割を果たせない。
価値の定義の不在: ownerが指摘するように「価値」とは「来訪者が楽しめるか」「競合サイトにない独自性があるか」などを指す。しかしreviewerはこの定義を持っていなかったため、価値評価ができなかった。

4. 過去記事で示された問題との連続性・再発

ワークフロー連載で示された問題とcycle-65〜66での再発

「レビューループの形骸化」（workflow-simplification記事より）

cycle-11でのレビュー未完了での完了宣言、cycle-12でのプランv3矛盾見逃しは、「レビューが形骸化している」問題だった。cycle-65〜66では形は異なるが本質的に同じ問題が再発した。reviewerがコンセプト文書の「本当の価値」を評価できず、細部の正確性チェックに終始した。

「PMのボトルネック化」（workflow-evolution記事より）

PM経由中継を廃止した目的は「PMをボトルネックにしない」ことだったが、cycle-66ではPM自身がコンテキストエンジニアリング（何を見せて何を見せないか）の設計を行わざるを得なかった。baised-context問題（Phase Fで既存サイトドキュメントをサブエージェントに見せてしまった）はPMのコンテキスト管理ミスであり、PM過負荷の別形態といえる。

「ルール違反の悪循環」（workflow-simplification記事より）

cycle-65〜66では「バイアス排除ルール」の違反が繰り返された。第1回はターゲットユーザー定義を見せたことによるバイアス（owner指摘: 19cb6756629）、第2回は指示設計のバイアス（19cb6fee624）、第3回はPhase Fでの既存コンセプト参照（19cb7a91599）。各回でルールを追加・明確化したが、次のフェーズで新たな形のバイアスが発生した。これは「ルールを増やすことで対処する悪循環」の再演だった。

「spawner実験での教訓」（spawner記事より）

spawnerで発生した「キャンセル不能問題」と類似した問題がcycle-66でも起きた。一度バイアスのかかった状態でPhase Fのサブエージェントを動かし始めると、そのコンテキストは変えられない。ownerが停止して全メモを無効化するという「外部からの強制停止」が必要になった点が共通している。

「自分の問題を自分で修正できない」（workflow-simplification記事より）

「ワークフローの簡略化タスクがワークフロー自体の問題で失敗した」という教訓がある。cycle-66では、「バイアスフリーなコンセプト策定」をバイアスのかかった状態でやり直そうとした。このメタ的な矛盾はPM自身が気づくことが本質的に困難であり、ownerの外部視点による2回の停止指示が必要だった。

5. サイクル所要時間の比較（数値まとめ）

サイクル	作業種別	所要時間	通常比
cycle-57	SEO改善（実装）	100分	基準
cycle-58	コンテンツ追加（実装）	234分	2.3倍
cycle-59	バグ修正・改善（実装）	144分	1.4倍
cycle-60	テスト整備（実装）	134分	1.3倍
cycle-61	大規模静的化（実装）	266分	2.7倍
cycle-62	ブログ書き直し（文書）	68分	0.7倍
cycle-63	Feed最適化（実装）	87分	0.9倍
cycle-64	調査・分析（文書）	251分	2.5倍
cycle-65	戦略策定（文書）	272分	2.7倍
cycle-66	戦略策定やり直し（文書）	約1940分	約19倍

cycle-66の32時間超は、実装系サイクルの典型的な所要時間（100〜134分）と比較して14〜20倍の長さとなった。

6. 機能不全の本質的原因

4スキル構成の機能不全は「スキルの欠陥」ではなく「作業の種類に対するスキルの適合性の問題」だった。

4スキル構成は「実装タスク」（コード変更、ドキュメント作成、バグ修正など）に対して設計され、そこで安定して機能してきた。この構成の前提は:

タスクが明確な成功基準を持つ
plannerが「何を作るか」を決められる
builderが「成果物」を実装できる
reviewerが客観的基準で評価できる

しかし「上流意思決定」（サイトコンセプトの策定、コンテンツ戦略の決定）は以下の特性を持つ:

正解が事前に不明であり、探索的に進める必要がある
バイアスの排除が構造的に困難（自分が持つバイアスは自分では気づけない）
「価値」の評価には外部視点（owner）の判断が不可欠
反復回数が予測不能で、4スキルのチェックリスト完了基準が馴染まない

cycle-64〜66は、4スキル構成が「実装タスク専用」であることを明確にした事例といえる。上流意思決定にはownerが直接関与する別のプロセスが必要だった。