Shuichiro Ogawa
English

Architecture

このサイトの構造。

本サイトは2つのアーキテクチャで構成されています。Web を配信するシステムと、コンテンツを制作するエージェント群。それぞれの構成と選定理由を公開します。

Part 1

System Architecture

Astro で静的生成し、Cloudflare Workers で配信する。Workers AI で wiki チャットを提供し、全体を無料枠内で運用する。

Tech Stack

技術スタック。

  • Astro 6 Web フレームワーク（ゼロ JS・静的生成）
  • Cloudflare Workers ホスティング（Static Assets + SSR）
  • Tailwind CSS 4 スタイリング（Vite プラグイン）
  • Workers AI Llama 3.3 70B による wiki チャット（無料枠）
  • TypeScript 6 型システム（astro check）

Cloudflare

Cloudflare 上のシステム構成。

サイトの実体は、Astro のビルド成果物を配信する単一の Cloudflare Worker です。どの機能を、どう使い、なぜ選んだかを示します。

  1. Workers（Static Assets）

    使用方法： astro build が生成した静的アセットを、@astrojs/cloudflare アダプタ経由で単一の Worker として配信する。

    選定理由： 静的配信だけなら他の選択肢もあるが、計画中の AI チャット（/api/chat）や KV / Vectorize などの bindings を同じ Worker ランタイムに差し込めるため、最初から Workers を土台に選んだ。

  2. Custom Domain（apex 割当）

    使用方法： wrangler.jsonc の routes で apex ドメイン jamjet-iqbal.com を Worker に直接割り当てる。DNS レコードと TLS 証明書は Cloudflare が自動作成・更新する。

    選定理由： apex 直下での公開を、DNS と証明書の手動管理なしに維持するため。

  3. wrangler（設定のコード管理）

    使用方法： name・compatibility_date・nodejs_compat・routes を wrangler.jsonc に集約し、アダプタが生成するデプロイ設定と合成して wrangler deploy で公開する。

    選定理由： デプロイ構成を git 管理のコードに置き、ローカルと CI のどちらからでも同一手順で公開できるようにするため。

  4. GitHub Actions からの自動デプロイ

    使用方法： 週次・月次の定点観測 workflow が、収集した note を commit / push した後に wrangler deploy を実行する。API トークンは Workers 編集＋対象ゾーン限定の最小権限。

    選定理由： PC の起動状態に依存せず wiki の更新と本番公開が続くようにするため。手動の変更は従来どおり npm run deploy で反映する。

  5. 無料枠優先と bindings の予約

    使用方法： 既定パスは Cloudflare 無料枠（Workers 10万リクエスト/日 等）で完結させる。AI / KV / R2 / D1 / Vectorize は未実装で、ロードマップ P3〜P7 の差し込み口として wrangler.jsonc に追記する設計。

    選定理由： 低コストを大前提に、有料・従量の機能は「差し込み口を用意して既定はオフ」で段階導入するため。

AI Chat

wiki チャット（/chat）。

Workers AI が公開 note の抜粋を根拠に回答するチャット機能。SSE ストリーミングで応答する。

モデル
@cf/meta/llama-3.3-70b-instruct-fp8-fast
検索方式
bigram 一致スコアリング（依存ゼロの日本語対応）
コンテキスト
上位4 note の抜粋を system prompt に注入
コスト
Workers AI 無料枠 10,000 Neurons/日で運用

Part 2

Agent Architecture

本サイトのコンテンツは、Claude Code のサブエージェント群が制作しています。収集、討議、批評、公開の4段パイプラインと、3段のモデル階層で構成されます。

Model Tiers

3段のモデル階層。

役割の性質でモデルを使い分け、論証の深さとトークンコストのバランスを取っています。

  1. claude-opus-4-6 [1m]

    討議の中核。討議リードの主張と相互反論、監査、共有前提への攻撃、学術批評の出典管理など、深い論証と 1M コンテキストでの長文読解が必要な役割に割り当てる。

    4 agents

  2. claude-sonnet-5

    収集・レビュー・ユーティリティ。read-only の構造化抽出やスコープの明確な検査は最新の Sonnet で十分な品質が出るため、コストを最適化する。

    5 agents

  3. claude-fable-5

    トークン消費が激しいため常設の割り当てはしない。特に深い理論ラウンドが必要な場面に限り、起動時のオーバーライドで都度指定する。

    0 agents（常設割当なし）

Agents

9体のサブエージェント。

4つのグループに分かれ、収集から批評までを分担します。各エージェントは起動時の dispatch（profile / persona / lens / axis / canon / mode）で役割を切り替え、旧27体分の視点を9体で担います。バッジは各エージェントの使用モデルです。

討議

4 agents
  • industry-lead Opus 産業ペルソナ（デザインファーム / 戦略コンサル / 独立オフィス）を persona 切替で担い、事業性と請求可能性を論じる
  • practice-auditor Opus 売上成立性・差別化の実在性・数値の方法論・生成物の責任・買い手の行動の5つの lens で役割の主張を検査する
  • disruption-provocateur Opus 破壊の歴史・グローバル価格裁定・プラットフォーム権力・消費者の無関心の4つの axis で共有前提を攻撃する
  • academic-critic Opus デザイン理論・教育学・産業/職能論の3つの canon に照らし、出典を引用して批判する

収集系

3 agents
  • source-researcher Sonnet 学術・ベンダー一次・公的統計・アナリスト・開発者証言・専門家私見・労働市場の7つの profile で出典つきに収集する
  • paper-screening-agent Sonnet 収集した文献候補を包含基準で選別し、重複を除去する
  • docs-researcher Sonnet フレームワークの現行 API・設定を公式ドキュメントで確認する

デザインレビュー

1 agents
  • design-reviewer Sonnet system-health / ui-analysis の mode 切替で、デザインシステムの健全性検査とページ UI の分析・実装指示を返す

ドキュメント

1 agents
  • doc-writer Sonnet 検証済みの事実から、コピペで実行できる手順書・運用ガイドを書く

Pipeline

収集から公開までの4段。

  1. 01 — Sources

    一次ソース層（read-only）

    source/review/ の収集コーパスと出典台帳が一次ソース層を担う。raw/ は不変資料の予約領域（hook が書込をブロック）。

  2. 02 — Collect

    収集とコーパス化

    収集系エージェントが一次情報優先・出典追跡・ポジショントーク除去のプロトコルに従い、出典台帳つきのコーパスを作る。

  3. 03 — Debate

    討議と批評（R1–R5）

    討議リード・監査役・外乱・学術 critic が多ラウンドで主張と反論を交わす。結論を丸めず、出典つきの対立表を主成果物とする。

  4. 04 — Publish

    wiki/note として公開

    統合結果を参照文献つきの note に書き戻し、index と log を更新してこのサイトで公開する。

Guardrails

安全策。

  • raw/ の不変性（PreToolUse hook が書込をブロック）
  • 未公開研究の統制（draft / so_theory フラグのない下書きは公開されない）
  • README とアセット一覧の同期（PostToolUse hook が更新を促す）
  • 討議の再現性（討議リードは Web に出ず、事前に固定した根拠のみで論じる）
  • 討議コストの記録（討議は一巡で終了し、エージェント別の消費を討議録に残す）
  • CI ゲート（push / PR ごとに wiki の健全性検査・型検査・ビルドを実行）
  • compact 復旧（圧縮前に判断構造を state file へ保存し、圧縮後は PreToolUse ゲートが復旧を強制する）
  • context 使用率の早期通知（60% 超過で PostToolUse / UserPromptSubmit が /compact-prep を提案する）

← ホームへ