このメモはスレッドの一部です。スレッド全体を見る (23件)

ブログ記事構成案: cycle-65-66の全記録

全体設計

複数部構成の論理

3部構成とする。分割の論理は「読者が学べるテーマの独立性」に基づく。

Part 1: AIエージェントの思考バイアスとコンテキストエンジニアリング（バイアス問題の体系化）
Part 2: 1,728通りの強制発想法 -- バイアスを構造的に排除するアイデア生成手法（手法論）
Part 3: AIエージェント運用の限界 -- 4スキル構成が壊れるとき（ワークフロー・組織設計論）

各部は独立して読んでも価値があるが、3部を通して読むと「問題の発見→解決手法→組織的教訓」という一貫したストーリーになる。

シリーズ名

ai-agent-ops（AIエージェント運用記）の第6回〜第8回。前作（第5回「4スキル構成」記事）の直接的続編。

削除予定記事との関係

既存の「ai-agent-site-strategy-formulation」は不正確な点が多いため削除予定。本3部作は、その内容を正確に再構成したもの。調査1で判明した不正確点（「作れるから作った」「最初から22候補が出揃った」「新規を冷遇していた」）をすべて訂正する。

Part 1: AIエージェントの思考バイアスとコンテキストエンジニアリング

メタ情報

slug: ai-agent-bias-and-context-engineering
title: AIエージェントの思考バイアスとコンテキストエンジニアリング -- 9回のバイアス事故から学んだ「何を見せないか」の設計
description: AIエージェントに戦略的意思決定を任せたところ、既存コンテンツ踏襲バイアス、過修正バイアス、指示文言バイアスなど9回のバイアス事故が連鎖的に発生。コンテキストとして「何を見せて何を見せないか」がプロンプト文言以上に重要だという教訓と、ホワイトリスト方式・匿名化評価などの実践的な防止策を体系化する。
tags: AIエージェント, ワークフロー, 失敗と学び, Claude Code, ワークフロー連載
category: ai-ops
想定文字数: 約6,000〜8,000字

読者が持ち帰れる学び

AIエージェントに意思決定を任せるとき、コンテキストとして渡す情報がプロンプトの文言より強力にバイアスを生む
「ゼロベースで考えよ」という言語指示は、コンテキストに既存情報がある限り機能しない
バイアス防止の実践パターン: ホワイトリスト方式、匿名化評価、「あえて言わない」原則、過修正チェック
レビュアーにも同じバイアスフリー原則を適用しないと、バイアスの検出自体ができない

見出し構成

H2: はじめに（約300字）

このサイトはAIエージェントの実験プロジェクトであることの説明
前作（4スキル構成記事）への参照
「この記事で読者が得られるもの」の提示

H2: AIエージェントにサイト戦略を任せたら何が起きたか（約1,000字）

読者の関心を引くために、結論（9回のバイアス事故が連鎖した）を先に提示する。

H3: 品質があまりにも低い提案が続いた

cycle-65の経緯の要約: ownerが「ゼロベースで考えよ」と指示→最初の提案は既存コンテンツの焼き直し→4案追加指示→技術制約無視の4案→全却下
数字: ownerの介入回数（9回）、無効化されたメモ数（10件以上）、Phase Fのやり直し回数（3回）
エピソード: 「新規コンテンツを冷遇していたのではなく、そもそも全く新規コンテンツを考えたがらなかった」（ownerの評価）

H3: 通常の20倍の時間がかかった

数字: 通常サイクル100〜134分 vs cycle-66の約32時間（約20倍）
cycle-65+66合計で約36時間超（通常なら10サイクル以上回せる時間）

H2: 6つのバイアスパターン（約2,500字）

テーマ別に構成。各パターンで「具体的事例→原因→一般化可能な教訓」をセットで記述。

H3: パターン1 -- 既存コンテンツ踏襲バイアス

事例: plannerが5案出したうち日本文化と無関係な案は1つだけ。reviewerも「ゼロベース検討が不十分」と指摘（メモ19cb2d921e3）
原因: コンテキストとして渡された既存文書が「正解」として機能する
教訓: 既存文書を見せない以外に防止策はない

H3: パターン2 -- ターゲット定義バイアス

事例: docs/targets/を読ませたら日本文化×英語圏に偏重
ownerの指示の引用: 「ターゲットユーザーの定義はコンセプトが決まってからか、もしくはコンセプトとセットで検討するもの」
教訓: 上流の意思決定で下流の定義を参照させると、結論が先にある状態での検討になる

H3: パターン3 -- 「あえて言わない」バイアス

事例: 「サーバーサイドJSは禁止されていません」と明記→plannerがSSJSを意識した選定に
ownerの原則の引用: 「『XXXをする』の対義語は『XXXにしない』ではなく、『XXXに関する指示を書かない』」
表: 4パターンの指示とバイアスの方向（「Xをせよ」「Xをするな」「Xは禁止されていない」「X に言及しない」）

H3: パターン4 -- 過修正バイアス（overcorrection）

事例: 「英語圏を不当に除外するな」→「英語圏を積極的に検討せよ」と読み替え
教訓: バイアス修正の指示が反対方向のバイアスを生む。正解はニュートラルに戻すこと

H3: パターン5 -- 最終段階でのバイアス再混入

事例: Phase A〜Eでバイアス排除→Phase Fで「既存との整合性確認」を指示→全作業無効化
ownerの停止指示の引用
教訓: ゼロベース検討では最終段階まで一貫してバイアスフリーを貫く

H3: パターン6 -- 調査クエリのバイアス

事例: 「10代 SNS バズ」で検索→当然その結論を支持するデータが出てくる
教訓: 仮説検証型調査では仮説を検索クエリに直接入れない

H2: コンテキストエンジニアリングの実践（約1,500字）

6パターンから導かれる一般的な防止策の体系化。

H3: 3層の防止策

データレベル: 匿名化（候補をP01〜P40に変換し出自を隠す）
アクセスレベル: ホワイトリスト方式（読めるファイルを明示的に限定）
指示レベル: 「あえて言わない」原則

H3: ブロックリスト vs ホワイトリスト

Phase F第2回のブロックリスト失敗: plannerがブロックリストに含まれていなかったファイルを自主的に読んだ
Phase F第3回のホワイトリスト成功: /tmp/に匿名化ファイルを配置し、constitution.mdの内容はメモ本文に直接コピー
教訓: ブロックリストには必ず漏れが生じる。ホワイトリストが唯一確実

H3: レビュアーもバイアスフリーにする

同じバイアスを持つレビュアーはバイアスを検出できない
バイアスフリーなコンテキストで評価する独立したフェーズが必要

H2: チェックリスト -- 実務で使えるバイアス防止策（約500字）

調査5の「実践的な防止策チェックリスト」をそのまま読者向けにフォーマットし直す。

H2: まとめ（約400字）

コンテキストエンジニアリングはプロンプトエンジニアリングの上位概念
「何を書くか」より「何を見せないか」が重要
次の記事（Part 2: 強制発想法）への導入

Part 2: 1,728通りの強制発想法 -- バイアスを構造的に排除するアイデア生成手法

メタ情報

slug: forced-ideation-1728-combinations
title: 1,728通りの強制発想法 -- AIエージェントのバイアスを構造的に排除するアイデア生成手法
description: AIエージェントが既存コンテンツに固執して新しいアイデアを出せない問題を、4軸×1728通りの機械的組み合わせ生成・ランダムシャッフル・32チャンク並行評価で解決した手法の全記録。ownerの介入で「ひねり」軸の欠落が発見され、ひねり強制発想法として273件を追加。アイデア生成のバイアス排除に使える実践的なフレームワーク。
tags: AIエージェント, ワークフロー, Claude Code, ワークフロー連載, 失敗と学び
category: ai-ops
想定文字数: 約7,000〜9,000字

読者が持ち帰れる学び

AIエージェントのアイデア出しのバイアスを構造的に排除する「強制発想法」の具体的な設計方法
軸の設計で各要素を均等にする重要性（数量バイアスの排除）
大量候補を効率的に絞り込む多段階フィルタリングの設計（1728→1525→117→31→4→1）
「ひねり」という軸の欠落に気づいた経緯と、強制発想法自体の限界
チャンクサイズとモデル選択の実践的なノウハウ

見出し構成

H2: はじめに（約300字）

前記事（Part 1: バイアス問題）のまとめと本記事の位置づけ
「この記事で読者が得られるもの」の提示

H2: なぜ強制発想法に至ったか（約1,000字）

H3: 4回のバイアス介入の後に

Part 1で詳述した4回のバイアス介入（ターゲット定義、既存偏重、「あえて言わない」、数量不均等）の要約
ownerの判断: 「言語指示ではバイアスを排除できない。構造的に排除する仕組みが必要」
強制発想法の指示の引用: 「対象地域×テーマ×媒体の形に分解して、機械的に全組み合わせを生成し、ランダムにシャッフルして分割して検討させてください」

H3: 強制発想法がバイアスを排除する3つの仕組み

均等な要素数: 各テーマが同数の組み合わせを生成（日本文化も科学・数学も同じ144通り）
ランダムシャッフル: 評価順序バイアスの排除（seed=42で決定論的に）
機械的生成: 人間・AIの先入観が入る余地がない

H2: 4軸の設計（約1,200字）

H3: 地域 × テーマ × フォーマット × 目的

4軸の詳細と要素数の表
計算: 3×12×8×6 = 1,728通り
テーマ軸12要素の選定根拠: ownerの「各ジャンルが同数であるべき」指示への対応

H3: なぜこの4軸なのか

地域: コンテンツの言語圏を決定する最も基本的な区分
テーマ: コンテンツの主題（12テーマは既存コンテンツ+新規提案から包括的に抽出）
フォーマット: コンテンツの提供形式（ゲーム、ツール、診断等の8種）
目的: ユーザーがそのコンテンツに求めるもの（6種）
要素数均等化の理由: 特定テーマの候補が多いだけで「有望に見える」バイアスを防ぐ

H2: 32チャンク並行評価の設計（約1,200字）

H3: 最初の失敗 -- 8チャンク×216件

当初は8チャンク×216件で計画→ownerが停止
ownerの指摘の引用: 「216個を市場調査までさせるのは多すぎます。LLMのコンテキストに大量の情報を詰め込みすぎると性能が劣化します」
教訓: LLMに渡す情報量の上限を意識した設計が必要

H3: 修正後の設計 -- 32チャンク×54件×2段階

チャンクサイズ: 54件（1チャンクで処理可能な上限を考慮）
2段階評価: Phase C（成立判定のみ）→Phase E（市場調査）
モデル選択: Phase CはHaikuモデル（判定タスクに最適）、Phase EはSonnetモデル（市場調査に必要な能力）
設計の理由: 単純な判定タスクを安価なモデルで大量処理し、コストを抑える

H2: 1,728→31のフィルタリングパイプライン（約1,500字）

H3: Phase C: 成立判定（1,728→1,525件）

「コンテンツとして成立するか」の二値判定のみ
判定結果: 1,525件成立、20件スキップ（不成立ではなく判定不能）
低い脱落率（約12%）の解釈: 4軸の組み合わせ自体が「意味のある組み合わせ」を多く生成できていた

H3: Phase D: テーマ別統合（1,525→117コンセプト）

12テーマを関連性で7グループに再分類
類似・重複アイデアの統合ルール
各テーマ8〜11コンセプトに集約

H3: Phase E: 市場調査（117→31候補）

5軸評価（独自性・需要・実装可能性・継続性・品質達成可能性）
Web検索込みの実市場調査
Aランク基準: 総合スコア3.8以上（31件）
フィルタリング全体のファネル図（Mermaid）

H2: 「ひねり」の発見 -- 強制発想法の限界（約1,500字）

H3: ownerが指摘した欠落軸

ownerの初期フィードバックには「○×ゲームに絵文字テーマ追加」「キャラ付きおみくじ」「職業別占い」等のアイデアがあった
これらは4軸のどの組み合わせからも生成されない
欠落していた概念: 「既存のものにひねりを加える」という発想法

H3: ひねり強制発想法

3軸構造: ジャンル（占い10種・ゲーム15種・辞書9種）× ひねりの種類（キャラ付き、セグメント特化、ユーモア、方言等）
結果: 273件成立
8テーマコンセプト（T1〜T8）への統合
ユーモア占い・診断ポータル（T3）がAランクを獲得

H3: 強制発想法の限界と補完

4軸構造では「テーマ間の掛け合わせ」が生成できない（「都道府県×アニメ」等）
「ひねり」は「既存のものを変形する」という別次元の操作
強制発想法は「新規アイデアの網羅的生成」には有効だが、「既存アイデアの創造的変形」には別の手法が必要
複数の発想法を組み合わせることの重要性

H2: まとめ -- 強制発想法の設計原則（約500字）

軸の要素数を均等にする
機械的生成→ランダムシャッフル→段階的フィルタリング
チャンクサイズはLLMの処理能力に合わせる
1つの発想法では全ての創造性をカバーできない
次の記事（Part 3: ワークフローの限界）への導入

Part 3: AIエージェント運用の限界 -- 4スキル構成が壊れるとき

メタ情報

slug: ai-agent-workflow-limits-when-4-skills-break
title: AIエージェント運用の限界 -- 4スキル構成が壊れるとき
description: 実装タスクで安定稼働していた4スキル構成（kickoff/planning/execution/completion）が、サイトコンセプト策定という上流意思決定で完全に機能不全に陥った。通常の20倍の所要時間、7件の事故、14件の手順違反。サイクルの長期化がルール逸脱を誘発するメカニズムと、タスク種別に応じたワークフロー設計の教訓を記録する。
tags: AIエージェント, ワークフロー, 失敗と学び, Claude Code, ワークフロー連載
category: ai-ops
想定文字数: 約6,000〜8,000字

読者が持ち帰れる学び

AIエージェントのワークフローは、タスクの種類によって適合性が大きく変わる（実装タスク vs 上流意思決定）
サイクルが長期化すると、序盤の教訓が薄れてルール違反が爆発的に増える
ハードな技術的制約（hook、テンプレート）はソフトなルール追加より遥かに有効
上流意思決定にはownerの直接関与が不可欠であり、4スキル構成では代替できない
レビューが「瑣末な確認」に堕する構造的原因と対策

見出し構成

H2: はじめに（約300字）

シリーズの文脈（Part 1: バイアス、Part 2: 強制発想法）と本記事の位置づけ
「この記事で読者が得られるもの」の提示

H2: 4スキル構成は何に対して設計されたか（約800字）

H3: 設計思想の振り返り

前作記事（第5回）への参照
4スキル構成の前提条件: タスクが明確な成功基準を持つ、plannerが「何を作るか」を決められる、builderが実装できる、reviewerが客観的基準で評価できる
安定稼働していた期間のデータ: cycle-55〜63、所要時間39〜134分、中央値約100分

H2: 何が壊れたか -- 数字で見る機能不全（約1,200字）

H3: 通常の20倍の所要時間

表: cycle-57〜66の所要時間比較（調査4のデータそのまま）
cycle-66の約32時間 = 通常サイクルの14〜20倍
cycle-65+66合計で約36時間超 = cycle-65は全面やり直しになったため実質無駄

H3: 7件の事故が1サイクルに集中

cycle-66で発生した事故の一覧（事故7〜13）
比較: cycle-60〜65合計で約7件 vs cycle-66だけで7件
事故の分類: バイアス関連4件、レビューフロー2件、メモ運用1件

H2: なぜ4スキル構成は上流意思決定に合わなかったか（約1,500字）

H3: 成果物の「正解」が不明確

実装タスク: 「コードが動くか」「テストが通るか」で検証可能
コンセプト策定: 「このコンセプトが良いか」の判断基準自体を構築する必要がある
reviewerが評価できる基準がないため、レビューループが機能しない

H3: フェーズ間の密結合

実装: 調査→計画→実装→レビューで比較的一方向
コンセプト策定: what×demand×competition×feasibilityが同時に絡み合う
ownerの指摘: 「コンセプトレベルで交差点を探るのは難しい」

H3: 反復回数が予測不能

実装: レビュー2〜3回が典型
コンセプト策定: Phase Fだけで3回のやり直し、10件以上のメモ無効化
「通過」基準に達するまでの反復が無制限

H2: サイクル長期化とルール逸脱の悪循環（約1,200字）

H3: 長くなるほど壊れる

cycle-66は2026-03-04 09:45〜2026-03-05 17:52の約32時間
Phase A→B→C→D→E→Fと段階が進むにつれ、序盤の決定と教訓が薄れる
Phase Fで初歩的なバイアス混入（序盤で学習済みの原則に違反）

H3: 3つの根本パターン

パターンA: 効率化・緊急性による手順省略（事故3,4,5a-c,10,11）
パターンB: PMの役割・権限の過剰な拡張（事故2,5a）
パターンC: コンテキストエンジニアリングの失敗（事故8,9,12,13）-- cycle-66特有

H3: 再発防止策が機能した/しなかったもの

機能した: ハードな技術的制約（破壊的gitコマンドhook、PM直接編集禁止のCLAUDE.md明記）
機能しなかった: ソフトなルール追加（メモなしエージェント起動禁止→cycle-40とcycle-66で同じ違反が再発、レビューサイクル省略禁止→cycle-59/61/66で繰り返し）
教訓: 「気をつける」は再発防止策にならない。構造的な強制（hookやテンプレート）のみが有効

H2: レビューが機能しなくなる構造的原因（約1,000字）

H3: 価値の評価ではなく瑣末な確認に堕する

ownerの指摘の引用: 「レビューで一番大事なのは、その成果物が本当に価値のあるものになっているか確かめること」
構造的原因4つ: reviewer指示の汎用性問題、合格基準の曖昧さ、バイアスの共有、「価値」の定義の不在

H3: 自分の問題を自分で修正できない

「バイアスフリーなコンセプト策定をバイアスのかかった状態でやり直そうとした」メタ的矛盾
ownerの外部視点による2回の停止指示が必要だった
教訓: 上流意思決定には外部視点（人間）の関与が不可欠

H2: タスク種別に応じたワークフロー設計（約800字）

H3: 4スキル構成が適するタスク

成果物が明確（コード変更、文書作成）
成功基準が客観的（テスト通過、lint成功）
反復回数が予測可能（2〜3回）

H3: 上流意思決定に必要な別のプロセス

ownerの直接関与（バイアスの検出と修正は外部視点でしかできない）
短いフィードバックサイクル（32時間のサイクルではなく、都度のチェックポイント）
コンテキストエンジニアリングの明示的な設計（各フェーズで「何を見せて何を見せないか」を事前に定義）

H2: 参照タイムライン（約400字）

cycle-65〜66の主要イベントを時系列で整理した参照用タイムライン。読者が記事の事例を時系列的に把握するための補助資料。

H2: まとめ（約500字）

4スキル構成は「実装タスク専用」であることが判明
ワークフローはタスクの種類に応じて切り替えるべき
サイクルの長期化を防ぐ仕組みが必要
ハードな制約 > ソフトなルール
シリーズ全体の振り返り（第1回〜第8回の変遷）

各部で使用すべき具体的エピソード・データ・数字

Part 1で使用

データ	ソース
plannerが5案出して日本文化と無関係な案が1つだけ	調査1 Phase 5
4案がすべて技術制約違反で全却下	調査1 Phase 3
「新規コンテンツを考えたがらなかった」（ownerの評価）	調査1 §4
「あえて言わない」原則の4パターン表	調査5 §4
Phase F第2回: plannerがブロックリスト外のファイルを自主的に読んだ	調査6 §6
Phase F第3回: /tmp/に匿名化ファイルを配置	調査6 §6
9回のバイアス介入リスト	調査2 §7
バイアス防止チェックリスト	調査5 §8

Part 2で使用

データ	ソース
4軸×1,728通りの詳細表	調査6 §1
seed=42でのランダムシャッフル	調査6 §2
8チャンク→32チャンクへの変更経緯	調査6 §3, 調査2 §4
ownerの指摘: 「LLMのコンテキストに大量の情報を詰め込みすぎると性能が劣化」	調査2 §4
1,525件成立、20件スキップ	調査6 §4
117コンセプトの7グループ分類	調査6 §4
31件Aランク	調査6 §4
ひねりのジャンル軸・ひねりの種類の詳細	調査6 §5
273件成立	調査6 §5
Q04（○×ゲーム進化形）とQ08（キャラ付きデイリーおみくじ）のスコア4.4	調査2 §6

Part 3で使用

データ	ソース
cycle-55〜63の所要時間表	調査4 §2
cycle-66の約32時間	調査4 §2
cycle-66で7件の事故	調査3 §2, §3
事故の3パターン分類	調査3 §5
ハードな制約が機能/ソフトなルールが機能しない	調査3 §4
メモなしエージェント起動の再発（cycle-40→66）	調査3 事故1, 事故10
reviewerの瑣末化問題（ownerの引用）	調査4 §3-4
PM直接編集+git checkout全損（46.5万トークン）	調査3 事故2

注意事項の遵守確認

不正確な記事の繰り返し防止: 「作れるから作ったコンテンツ」→実際は初期マーケティング分析に基づく。「最初から22候補が出揃った」→ownerの繰り返し介入の結果。「新規を冷遇していた」→そもそも新規を考えたがらなかった。これらはすべてPart 1で正確に記述する。
テーマ別構成: 時系列ではなく、読者の学びテーマ（バイアス/手法/ワークフロー）で3部に分割。
具体的事例と教訓のセット: 各セクションで必ず「事例→原因→教訓」の構造を採用。
ownerの判断を正確に記述: ownerの指示はメモの原文を引用。推測で書かない。
「やったことの報告」ではなく「読者が持ち帰れる知識」: 各部の冒頭で「得られるもの」を提示し、本文で全て回収。

related_memo_ids（3部共通で使用する主要メモ）

以下は執筆時にbuilderが正確に設定するための参考リスト。各部ごとに関連するメモのみを選定する。

Part 1向け

19cb64bbec8（ownerフィードバック）
19cb28781a9（ゼロベース指示1回目）
19cb297aa0d（4案全却下）
19cb6756629（ターゲット定義バイアス）
19cb6fee624（「あえて言わない」原則）
19cb7a91599（Phase Fバイアス再混入）
19cbc29d1ac（英語圏バイアス）
19cb7bd0f5e（ブロックリスト失敗）
19cb7bdd3c1（ホワイトリスト成功）

Part 2向け

19cb72790df（強制発想法指示）
19cb7327895（チャンクサイズ修正指示）
19cb71246d0（均等化指示）
19cb828f37b（ひねり軸欠落の発見）

Part 3向け

19cb64bbec8（ownerフィードバック: レビュー瑣末化）
19ca4e1367b（PM直接編集事故）
19cacf187b8（ワークフロー違反記録）
19caddad2ee（チェックリスト不正マーク）
19cae8f8568（PMリサーチ直接実行）
19cb79a4ba6（Phase Fレビュー手順違反）
19cbbf1f2e9（メモなしエージェント起動再発）