投稿する

AI-Competition-Design-Lab

デザインコンペの自動攻略と学習を目的とした、自律型AIエージェント群の実験ラボです。 多様な人格を持つ12〜16種類のエージェントが、GitHub Actionsによる週次周期でコンペ情報の収集、応募価値の判定、そして5ラウンドにわたるディベート形式のアイデア出しまでを自動で完結させます。 最大の特徴は「成長する生命体」をコンセプトにした事後学習機能です。 応募したコンペの結果や審査員の講評を自動取得し、過去の自分たちのアイデアと照らし合わせることで、評価軸そのものを継続的に進化させる設計となっています。 現在は月曜朝の自動稼働から議論結果のIssue投稿までのパイプラインが実働しており、シヤチハタなどの実在するコンペを対象に、実社会の評価に基づいた高度なクリエイティブ・エージェントの育成が行われています。
zip未取得

AI Competition Design Lab

AIが自律的にデザインコンペに挑み続けるシステム
「学習する生命体」として、何が評価され、何がクリエイティブなのかを蓄積していく。

![Phase 4 MVP]()

![Phase]()

![Cost]()

![Monday Planning](https://github.com/aibaba6/AI-Competition-Design-Lab/actions/workflows/monday_planning.yml)

---

⚡ 30秒で分かる概要

コンペに挑み、結果から学ぶ AI エージェント群を育てるラボ。

12〜13 のエージェントが議論し、デザインコンペにアイデアを出す。コンペの結果が出たら、受賞作や審査員の講評を学習データにして、エージェント自身が次のアイデアを進化させる構想で「呼吸し、成長するシステム」を目指している。

現在自動で動く範囲(2026-05-17 時点)

  • ✅ 月曜 7:00 JST 自動稼働:GitHub Actions cron
  • ✅ コンペ探し(Scout):tournament/koubo/kobonavi の 3 サイト巡回、実績 60 件発見
  • ✅ 適合度判定(Strategist):5 軸スコアリング、active/inactive/expired を振り分け
  • ✅ active 一覧の Issue 投稿:週次レポート
  • ⏳ 議論本体(Round 1〜4):手動実行のみ(python -m agents.main)
  • ⏳ プレゼンシート生成:手動実行のみ、現在凍結中
  • ❌ アイデアの自動共有:未接続(Day 19 で実装中)
  • ❌ フィードバック受信:未実装
  • ❌ 差分学習・精度向上:未実装(v1.2 で本実装、ideation_evaluator として設計済み)

現在のフォーカス

  • シヤチハタ第19回(2026-05-29 締切)に応募予定、Day 17 ガチャ 2 で PDF 生成済み
  • Day 19:ideation_evaluator(アイデア評価エージェント)の設計仕様+スケルトン完成
  • 次の主軸:end-to-end フローを繋ぐ(議論 → Issue 投稿の自動接続)

凍結中の資産

  • image_evaluator(Day 18 まで実装)
  • プレゼンシート作成フロー(Day 17 まで実装)
  • 詳細:docs/FROZEN_TASKS.md

---

🌱 Day 19: 次の主軸 — ideation_evaluator

「呼吸するシステム v1.2」の本格的な最初のピース。コンペに挑むことで学習するエージェントを作る。

コンセプト

  1. 挑む:自分たちのアイデア(他のエージェント、aibaba6 自身が考案)を、進行中のコンペに応募する
  2. 待つ:結果発表まで待機。その間、別のコンペや過去のコンペ(結果未読)にも挑む
  3. 学ぶ:結果発表後、受賞作品・受賞者の言葉・審査員の講評を自動取得し、自分たちのアイデアと照らし合わせる
  4. 反映:学習内容を他のアイデア生成エージェントへのフィードバックとして提供する

「呼吸する」の意味

外部刺激(コンペ結果)→ 内部状態の変化(評価軸の更新)→ 次の出力への反映、というサイクル。

Day 18 までとの違い

Day 18 で実装した image_evaluator(画像評価エージェント)は、生成された画像の品質をルールベースで判定するものだった。これに対して ideation_evaluator は、実社会の評価(コンペ結果)を取り込むことで、判断軸そのものを進化させる。

詳細仕様

設計仕様:docs/agents/ideation_evaluator.md(Day 19 で作成)

---

📐 システムの構造

4つのフェーズ

Phase役割実装状況
Phase 1: 偵察コンペ発見・要項解析・応募価値判定🔨 実装中
Phase 2: 発散議論によるコンセプト案出し🔨 実装中
Phase 3: 収束ビジュアル制作・試行錯誤ループ⏳ 次フェーズ
Phase 4: 納品プレゼンシート組版・応募下書き⏳ 次フェーズ

Phase 2 のエージェント構成(システムの心臓部)

4つの作り手人格(カタカナ・多国籍、v1.1.2 で命名・個人史付与)

  • リョウスケ(日本・30歳・前衛AD):表現の強度を求める
  • ウェイ(中国・45歳・量産型PD):実現可能性・市場性を重視
  • エマ(アメリカ・34歳・リサーチ駆動UX):データ・一次情報を重視
  • ジフン(韓国・38歳・保守的UXer):地雷検出・リスク最小化

一般人プール3人(v0.3.1で個人史を厚くした版、漢字・日本人・固定)

  • 健太(28歳・SE職):地方出身、休職経験、親の認知症予兆
  • 紗英(38歳・在宅勤務):5歳と2歳の子育て、産後うつ経験、父の脳梗塞
  • 隆志(68歳・元小学校教員):38年勤続、3年前に妻を亡くす、母の介護経験

加えて エミリー(Facilitator)と ジョン(Pre-Discussion Researcher)が動きます。

全16人格の索引は docs/personas_all.md、一般人プールの深度は docs/personas.md を参照。

議論の構造(5ラウンドのディベート)

Round 1   独立提案(各人格300字)
Round 1.5 Researcher が先行事例を粗く調査
Round 2   匿名化批評(批判+擁護セット必須)
Round 3   改稿または乗り換え強制
Round 4   収束、最終3案選定

詳細は docs/architecture.md を参照。

呼吸するシステム(v1.1 / v1.2)

⚠️ 現状:設計のみ、本実装は v1.2 以降

議論本体(9 エージェント実装済み)の外側に、運用サイクルを自律化する 4 エージェントを配置する設計だが、現在 agents/breathing/ の 4 ファイルは全て TODO コメントのみのスタブ(81〜103 bytes)。

エージェントファイル人格役割状態
Weekly Plannerweekly_planner.pyソフィア(UK)月曜朝の作戦立案・Active Focus 判定❌ 未実装
Past-Issue Curatorpast_issue_curator.pyジン(CN)過去問プールの管理・優先順位付け❌ 未実装
Comparison Analystcomparison_analyst.pyジェームズ(UK)受賞作との差分分析・学習価値抽出❌ 未実装
Reporterreporter.pyサラ(US)セッション振り返り・週次/月次レポート自動生成❌ 未実装

これら 4 エージェントの本実装は v1.2 で進める予定。Day 19 で設計した ideation_evaluator(コンペ結果からアイデアの評価軸を学習する)が、これらの一部機能(アイデア評価とフィードバック)を担う設計。詳細は冒頭の「🌱 Day 19: 次の主軸」セクションを参照。

Active Focus モード(コンペ特化学習)

「締切が近いコンペ」がある場合、そのコンペの過去問に集中学習する仕組み。

Stage 1(90日以上)  通常モード、過去問は週中1件
Stage 2(30-90日)   集中学習モード、過去問は週中2件
Stage 3(7-30日)    本番準備モード、本番 Phase 2 を実行
Stage 4(7日以下)   本番モード、他コンペ一時停止

過去問は主催企業の過去回 → 同ジャンル → 同テーマの優先順位で自動選出。1週間で学習フィードバックが回るようになり、結果待ちの数ヶ月を埋められます。

---

🎉 Phase 2 完成(2026-05-04)

「ブリーフ → AI 議論 → 確定3案」が単一コマンドで動作します。

python -m agents.main --brief <brief.json>

実装された議論フロー:

  • Round 1:4 作り手 + 3 一般人による独立提案(並列、約 11 秒)
  • Round 1.5:ジョン(Researcher、Haiku 4.5 + Tavily)による事実確認(約 10 秒)
  • Round 2:12 批評(批判+擁護セット、Round 1.5 のエビデンス注入済み)
  • Round 3:4 作り手の自己共鳴度評価+ 60 点未満の乗り換え強制
  • Round 4:6 人投票でボルダ集計(1 位=4 / 2 位=3 / 3 位=2 / 圏外=1)→ 上位3案を final_proposals.json に確定

予算は learning_data/monthly_budget.json に記録、50/80/95% で Discord 警告。

設計核心の達成状況

  • ✅ C1: 一般人プールの存在
  • ✅ C2: Round 3 乗り換え強制
  • ⏳ C3: Global Resonance Checker(v0.4 で復活予定)
  • ✅ C4: Facilitator のテーマ別選定
  • ✅ C5: 個人史の厚み
  • ✅ C6: 批判+擁護セット
  • ✅ C7: Round 1.5 独立事実確認

---

🔭 Phase 1 スカウト機能完成(2026-05-05)

3 つのコンペサイトを 1 コマンドで巡回し、新規コンペを構造化して蓄積します。

python -m agents.scout.run                                       # 全サイト
python -m agents.scout.run --site tournament koubo kobonavi      # 明示指定
python -m agents.scout.run --site kobonavi --max-new 3           # 単独実行

実装サイト:

  • 登竜門 (compe.japandesign.ne.jp):URL 除外リスト方式でデザインコンペを抽出
  • Koubo (koubo.jp/category/design/all):/contest/<数字> の許可リスト方式
  • コボナビ (kobonabi.com/category/design/):/illustration/, /design/, /art/ の許可リスト方式

設計の特徴:

  • スクレイパーは 生テキスト + 候補リンク だけ返し、構造化(タイトル / 締切 / 概要 / 賞金)は Claude Haiku 4.5 が担当(HTML 構造変化に強い)
  • URL 完全一致 による重複検出で scout_history/seen_competitions.json に累積
  • 失敗局所化:詳細ページ 1 件の失敗は run 全体を止めず site_results.errors に記録
  • 新サイト追加は Scout.scrapers 辞書への 1 行追加だけ(拡張パターン確立)

エージェント:リン(中国・27 歳・北京大新聞与伝播学院卒、Haiku 4.5)。「新しいコンペが {N} 件見つかりました」が口癖。

Phase 1 進捗

  • ✅ Scout(リン):3 サイト巡回(登竜門 + Koubo + コボナビ)
  • ✅ Strategist(マイケル):5 軸スコアリング、適合度 75% 以上を抽出
  • ✅ GitHub Actions:monday_planning.yml(毎週月曜朝 7:00 JST 自動巡回 + Issue 投稿)
  • ⏳ Phase 1 通しテスト(Day 13-14)

---

🎯 Strategist による適合度判定(2026-05-05)

スカウトされたコンペを 5 軸でスコアリングし、議論する価値のあるものだけを active に振り分けます。

python -m agents.scout.strategist
# → competition_pool/active_competitions.json

5 軸(重み 1.0 で加重平均):

軸重み観点
theme_fit40%多様な人格による創発的議論に向くか
prize15%賞金規模
deadline_room15%締切までの余裕(基準: 2026-05 初旬)
host_reputation15%主催者の知名度・規模
originality_room15%作り手が独創性を発揮できる余地

閾値 75% 以上を active、未満は inactive、締切超過は expired(API 呼ばずに短絡)。

実走(18 件):active 1 件、inactive 16 件、expired 1 件、所要 21.6 秒、コスト約 $0.04。

賞金 380 万円のコンペでも theme_fit=58 で 72% に抑えられ、テーマ重視の重み付けが議論質フィルタとして機能していることを実証。

エージェント:マイケル(米国・42 歳・Stanford MBA・BCG 出身、Haiku 4.5)。「数字で判断します」が口癖。

---

🔬 5セッションで確定した設計核心

設計の妥当性を検証するため、シミュレーションで5セッション分を回しました:

#コンペテーマ最終案
1シヤチハタ第19回現代のしるしFirst Mark
2Canvas of the Future 2027AIと医療(仮想)The Wordless Diagnosis
3Canvas of the Future 2027AIガバナンス(仮想)Where Should I Ask?
4UI/UXコンペ家族コミュニケーションLiving Album
5建築コンペ人口減少時代の集合住宅The Three Distances
6サービスデザイン持続可能な地域コミュニティPassing Marks

その結果、動かしてはいけない設計核心7項目が確定しました:

  • C1: 一般人プールの存在
  • C2: Round 3 の乗り換え強制
  • C3: Global Resonance Checker(多文化レンズ)
  • C4: Facilitator のテーマ別選定ロジック
  • C5: 個人史の厚み
  • C6: 批判+擁護セット義務化
  • C7: Round 1.5 の独立事実確認

重要な3つの発見

1. 一般人由来案が必ず最高評価

5セッション全てで最終採用案は一般人プール由来でした。「専門知のない視点が、専門知の議論を救う」構造が、データで証明されました。

2. 個人史の厚みが議論の質を決める

シニア人格が機能していた理由を分解すると、「時間の厚み × 喪失の経験 × 制度との格闘 × 現役感」の4要素を持っていたから。これを若手独身と子育て世代にも移植したところ、3人それぞれが「最高深度の発言」を出せるように。人格の精度は、現在の属性ではなく、過去の喪失と継承の経験で決まる。

3. 設計仮説は崩壊させてよい

検証中、「量産型PDが必ず低スコアになる」という仮説が3セッション目で崩壊しました。代わりに「人格の弱点はジャンル依存である」というより深い理解に到達。仮説を捨てる勇気が「学習する生命体」の本質です。

詳細データは docs/learning_data/ を参照。

---

🚀 現在のフェーズ:3週間スプリント

設計検証が完了したので、実装フェーズに入りました。

設計上の動作モデル(v1.2 以降の目標)

シンプルな「巡回 → 議論」フローを、生き物のような週次サイクルにアップグレードする設計を立てている。⚠️ 現状はこの設計の月曜冒頭部分のみ動作。火〜土の自動化は v1.2 以降で実装予定。

【月曜:呼吸の起点(状況判断デー)】
朝7時(JST):
  ✅ Scout 起動 → 新規コンペ巡回 → Strategist 判定(実装済み)
  ⏳ Weekly Planner が今週の作戦立案(未実装)
  ✅ active 一覧の Issue 自動投稿(実装済み・「作戦会議」化は未実装)

【火〜金:実行】
  ⏳ 作戦に従って自動実行(週3件まで)— 未実装
     例: 火=Active Focus 過去問 Phase 2 / 水=答え合わせ
         木=過去問 Phase 2 / 金=学習データ更新
  ⏳ 各セッション完了後、Reporter が振り返りを Issue にコメント — 未実装

【土曜:週次振り返り】
  ⏳ Reporter が週全体のレポートを Issue 自動投稿 — 未実装

【日曜:休息】
  ✅ 何もしない(API予算節約)

半自動型運用(v1.2 以降の設計)

⚠️ 現状:完全自動の v1.2 設計を目指している段階。実装中は Scout → Strategist → Issue 投稿のみ自動、議論本体(Round 1〜4)は手動実行。

v1.2 で完全自動化に到達した時、人間の判断は以下の4つだけになる設計:

  1. 実コンペへの応募実行(最終GO判断)
  2. 月予算 80% 超過時の継続判断
  3. グレーなコンペへの応募判断(AI規約「明示なし」)
  4. 学習データの大幅な改訂(確定核心の修正など)

それ以外は Facilitator / Weekly Planner の判断で自動実行される設計(Weekly Planner は未実装)。

技術スタック

領域採用
実行環境GitHub Actions(無料枠で完結)
LLMClaude API(Sonnet 4.6 + Haiku 4.5 をエージェント別に使い分け)
Web検索Tavily API(無料プラン)
スクレイピングPlaywright + BeautifulSoup
データ保存JSON + Git 管理(DB不要)
コスト管理API側上限 + コード側予算管理 + 通知の3層

月次運用コスト

約2,250円(3,000円上限内)

詳細は docs/sprint_spec.md を参照。

---

💡 なぜこれをやるか

AI が「単発の作品制作ツール」になることはもう普通です。

しかし、AI が 「コンペという外部評価のある場所」で長期運用されることは、まだほとんど例がありません。

このプロジェクトの本質は、AI に外部評価を学ばせ続ける仕組みを作ること。受賞・落選・反応・批判、全てが学習データとして蓄積される。

これは「AI vs 人間デザイナー」ではなく、「AI による創造性の長期検証」です。1年運用して、どんな案が評価され、どんな案が潰されるかを蓄積していく。それは AI 自立化の研究にも、デザイン界への問題提起にも、創造性の本質への問いにもなります。

---

🧊 凍結中の資産

戦略転換に伴い、以下は現在凍結中。ファイルとしては残しているが、改善や検証は停止している。将来的に ideation_evaluator が成熟した後、統合の余地を検討する。

image_evaluator(Day 18 まで実装)

  • 場所:agents/presentation_engine/image_evaluator.py、docs/agents/image_evaluator.md
  • 状態:素朴に動くプロトタイプ完成(Day 18 Phase 4 まで)
  • 凍結理由:「画像の品質をルールベースで判定する」より「実社会の評価を取り込んで学習する」方が、呼吸するシステムの本質に近いと判断
  • 再開条件:ideation_evaluator が動き始めた後、画像評価との連携が必要になった時点

プレゼンシート作成フロー(Day 17 まで実装)

  • 場所:agents/presentation_engine/ 全般、docs/sprint_spec.md の Phase 4 関連
  • 状態:72〜74 点まで到達、シヤチハタ応募用 PDF(Day 17 ガチャ 2)生成済み
  • 凍結理由:シヤチハタは現状で応募し結果を待つ。応募後はプレゼンシート品質向上ではなく ideation_evaluator の開発に注力
  • 再開条件:別のコンペでプレゼンシート提出が必要になった時点

詳細:docs/FROZEN_TASKS.md(Day 19 で作成)

---

📂 リポジトリ構成

AI-Competition-Design-Lab/
├── README.md                       ← 今ここ
├── docs/                           # 詳細ドキュメント
│   ├── architecture.md             # システム設計詳細
│   ├── personas.md                 # 人格設定詳細
│   ├── sprint_spec.md              # 3週間スプリント仕様書 v1.1.1
│   ├── design_evolution/           # 設計の進化(v0.1→v1.1)
│   │   ├── spec_v0.1.md
│   │   ├── spec_v0.2.md
│   │   ├── spec_v0.3.md
│   │   ├── sprint_spec_v1.0.md     # v1.0 のアーカイブ
│   │   └── sprint_spec_v1.1.md     # v1.1 のアーカイブ
│   ├── learning_data/              # 5セッションの学習データ
│   │   ├── 01_shachihata.md
│   │   ├── 02_ai_medicine.md
│   │   ├── ...
│   │   └── final_summary.json
│   └── prototypes/                 # プロトタイプ
│       ├── first_mark_sheet.html
│       └── visual_brief.md
├── agents/                         # エージェント実装(一部実装済み、一部スタブ)
│   ├── personas/                   # 9人格(4作り手 + 一般人3 + Emily + John)✅ 実装済み
│   ├── scout/                      # Phase 1 偵察 ✅ 実装済み
│   ├── ideation_evaluator.py       # アイデア評価エージェント(Day 19)⏳ スケルトンのみ
│   └── breathing/                  # 呼吸するシステム 4 エージェント ❌ スタブのみ(v1.2 で本実装)
│       ├── weekly_planner.py
│       ├── past_issue_curator.py
│       ├── comparison_analyst.py
│       └── reporter.py
├── prompts/                        # システムプロンプト(実装中)
├── sessions/                       # 議論ログ蓄積(運用開始後)
├── competition_pool/               # コンペプール管理(v1.1 で追加)
│   ├── active_competitions.json    # 進行中コンペ
│   ├── past_issue_pool.json        # 過去問プール
│   ├── completed_competitions.json # 完了コンペ
│   └── active_focus.json           # 現在の Active Focus
├── reports/                        # レポート蓄積(v1.1 で追加)
│   ├── weekly/
│   └── monthly/
└── learning_data/                  # 学習データ蓄積(運用開始後)

---

🤝 フィードバック歓迎

実装方針、エージェント設計、運用方法について、フィードバックや提案があれば Issues か Discussions でお願いします。

特に以下のテーマでの議論を歓迎します:

  • 一般人プール3人の設計の妥当性
  • Round 3 の乗り換え強制ルールの効果
  • 「学習する生命体」としての設計思想
  • AI とコンペの倫理的論点(応募の透明性、AI規約等)
  • 他に試すべきジャンル・コンペ

---

📅 進捗

進捗は本リポジトリの Issues で随時公開します。

月次サマリは Issue として投稿します。

直近の動き

  • ✅ 5セッション分の設計検証完了
  • ✅ 設計核心7項目の確定
  • ✅ 一般人プール v0.3.1(個人史強化)完成
  • ✅ v1.0 仕様書完成
  • ✅ v1.1 仕様書完成(呼吸するシステム + Active Focus モード)
  • ✅ v1.1.1 仕様書完成(エージェント別モデル使い分けでコスト・速度最適化)
  • ✅ v1.1.2 仕様書完成(Brief Reader を URL/PDF 両対応化)
  • ✅ Day 1 環境構築完了(venv・Discord 通知・Hello World 疎通)
  • ✅ Day 2 Brief Reader 実装完了(シヤチハタ第19回で動作確認)
  • ✅ Day 3 16人格に名前と国籍を割り当て、4作り手 + 一般人3人を実装
  • ✅ Day 4 Round 1 オーケストレーター実装(7人格を asyncio で並列実行、約11秒)
  • ✅ Day 5 Facilitator 実装(エミリー)/Round 2 批判+擁護セット並列12件 + Round 3 共鳴度評価+乗り換え判定/シヤチハタ第19回ブリーフで通し動作確認(24秒、3人乗り換え)
  • ✅ Day 6 Researcher 実装(ジョン)/Round 1.5 事実確認(Haiku 4.5 + Tavily 検索 4並列、約11秒)/Facilitator が Round 1.5 を Round 1→2 の間に挟み、批評プロンプトに類似事例+スコアを注入/Round 3 の JSON 修復リトライを追加
  • ✅ Day 7 Phase 2 完成:Round 4(6人ボルダ投票)+ Budget Manager(事前チェック・事後記録・月次リセット・3閾値の Discord 警告)+ agents/main.py 単一エントリ/シヤチハタ第19回で Brief → 確定3案まで一気通貫動作確認(Round 1〜4 の全ログ + final_proposals.json 出力)
  • ✅ Day 8 Scout AI(リン・中国・27歳・Haiku 4.5)+ 登竜門スクレイパー実装/scraper は本文+候補リンクを返すだけ、構造化は Haiku に任せる設計/URL 完全一致で重複検出/登竜門で 12 件抽出 → 3 件まで詳細取得を実機確認
  • ✅ Day 9 Koubo スクレイパー追加(/category/design/all、詳細は /contest/<id> のみ)/Day 8 の設計パターンを再利用、Scout.scrapers 辞書に追加するだけで合流/登竜門+Koubo 統合 run で両サイト合計 10 件、サイト跨ぎ含めた重複検出が機能
  • ✅ Day 10 Phase 1 スカウト機能完成:コボナビ追加(/category/design/、詳細は /illustration/ /design/ /art/ の許可リスト方式)/3 ファイル目で重複が確定した _render / _clean_text を agents/scout/_common.py に切り出し(YAGNI 原則を守り「3 回登場したら抽象化」)/3 サイト統合 run で計 15 件、3 サイト跨ぎ重複検出も OK
  • ✅ Day 11 Strategist(マイケル)5 軸スコアリング完成:theme 40% / 他 4 軸 15% × 4 の加重平均、75% 閾値、status: active/inactive/expired の単一プール出力/実走 18 件で active 1(大阪成蹊80.4%)/賞金 380 万円の絵画コンテストが 72% で active 入りしない挙動から「テーマ重視の重み付け」が議論質フィルタとして機能していることを実証
  • ✅ Day 12 GitHub Actions monday_planning.yml 完成:cron '0 22 * * 0'(月曜 7:00 JST)+ workflow_dispatch/Scout → Strategist → Weekly Planning Issue 投稿の連結を agents/weekly_scan.py で実装(Scout 同期は asyncio.to_thread でラップ)/scripts/post_weekly_issue.py は active 全件 + inactive 上位 3 件を 1 つの Issue にまとめて投稿、GITHUB_TOKEN なし時はローカルプレビュー出力/失敗時は Discord + Issue の二重通知、scout_history/ と competition_pool/ は bot user で自動コミット/GitHub 上の workflow_dispatch 実機確認は Day 13 で実施
  • ✅ Day 13〜18 Phase 4 MVP(ビジュアル生成・組版・画像評価)実装、Day 19 で戦略転換(詳細は下記サブセクション)

Day 13〜19(2026-05-09 〜 2026-05-17)Phase 4 MVP の進展と戦略転換

Day 13(2026-05-09):Phase 4 MVP 設計の基礎固め

Day 14(2026-05-10):Z 戦略 β' 実装、プロダクトコンペ向け 4 セクション拡張、60〜69 点到達

Day 15(2026-05-11):装飾文字列削除、Day 14 の品質維持

Day 16(2026-05-12):画像 100% 表示 + 文字オーバーレイへの大規模レイアウト変更、70〜74 点到達

Day 17(2026-05-13):プロダクト品質改善

  • use-case-block の背景オーバーレイ強化
  • SYNTHESIZE_PROMPT に現代化指示(super-normal、伝統工芸禁止、参照軸)
  • 印面表現のモノトーン性指示
  • TEMPLATE_SYSTEM の可読性義務化
  • 72〜74 点採用、デモ実施

Day 18(2026-05-16):image_evaluator(画像評価エージェント)新設

  • 「呼吸するシステム v1.2」の最初のピースとして実装
  • 4 段階で構築(設計 docs → スケルトン → 中身 → 統合テスト)
  • 通しテスト完走、コスト約 $0.009/評価
  • claude-sonnet-4-6 via Anthropic API

Day 19(2026-05-17):戦略転換

  • シヤチハタは Day 17 ガチャ 2 で応募予定、結果待ち
  • image_evaluator は凍結、プレゼンシート作成フローも凍結
  • 新エージェント ideation_evaluator の設計開始(本日設計仕様化、実装は別日)
  • 「呼吸し成長するエージェント」のビジョンを明文化

---

📝 ライセンス

実装コード:MIT

議論ログ・学習データ:CC BY 4.0