背景

• fukuで新しくAI for Scienceに関するオウンドメディアを立ち上げる
• AIの進歩は著しく、すでに執筆支援にAIを利用することが多い

課題

• リッチなCMS（e.g. WordPress）とLLMは相性が悪そう
  • 記事ページにしか情報を残せない（参考資料はリンクで貼るしかなく、LLMが取得する手間がかかる）
  • LLMがCMSのエディターを操作できない（APIがなければbrowser useするしかないが、現状実用に足る精度にない）
• タスク管理のためのNotionもLLMと相性が悪い

方針

• AIエージェントを十全に活用した新時代のオウンドメディアを作りたい

技術選定の基準

• 基本的な作業はエージェントが実施するため、エージェントにとって情報が参照しやすいようにすること（ローカルにファイルを保存するなど）。
• 人間が一部作業をマニュアルで行うことも考慮する。機能としてはMarkdownで十分だが、エディタでMarkdownを直接編集する場合、画像を挿入する際に面倒、非エンジニアでも操作しやすいGUIエディタがあるとベター。ただし、ドラッグ＆ドロップやクリップボードからの貼り付けに対応して、自動で画像フォルダに格納してくれるならなんでも良い。
• 完成した記事はインターネット上の自社オウンドメディアにデプロイできるようにすること。

ユーザー体験

編集会議

• エディターは編集会議にてオウンドメディアとして扱いたい内容を議論、リストアップ
• 扱いたい内容をエージェントに与える
• エージェントは記事候補をリストアップし、GitHub Issuesに追加
  • Issueのタイトルにはタイトル案をプレインテキストで、Issueの本文にはターゲットキーワード、小見出し案、月間検索ボリューム、競合性、推奨文字数、想定読者をYAML形式で記載してIssueを作成、articleとstatus/screeningのラベルを付与する
• エディターはstatus/screeningラベルの記事候補を確認し、ライターに執筆してもらうものを選別しstatus/approved を付与する。没案にはstatus/rejected を付与する。

アサイン

• ライターはローカルにて（Cursorなどを通じて）エージェント経由でGitHub Issuesからarticleラベルが付与されたもので、担当者がいないissue（＝執筆可能な記事候補である）をリストアップする。
• エージェントに自身の専門・興味を伝え（あるいはあらかじめ設定する）、執筆するものを選び、エージェントがissueにstatus/assigned ラベルを付与、assigneeにライターを設定する。エージェントはライターのローカル環境にて、本issueと対応した名前のブランチを作成する。
• ライターはエージェントとの対話を通じて執筆戦略を立てる（どこで何を調べるか、どんな内容を書くか）。この際Issueに設定された想定読者、小見出し案、推奨文字数は参考にするが、必ずしも守らなくても良い。

調査

• ライターはエージェントに知りたいことを伝える、あるいは直接URLのリストを与える（「このページを調べて」のように与える）
  • エージェントはウェブ検索、文献検索（PubMed、arXiv）などのツールを利用して情報収集。情報源のPDFはローカルストレージの当該記事専用のディレクトリ（ディレクトリ名は日付とタイトル案）内のreferencesディレクトリにフラットに保存する。references/list.csvにはテーブル形式で、元記事タイトル、保存ファイル名、URL、取得日付、内容のサマリー、この記事においてどのように引用できるか・参考にできるのかなどの情報収集の結果とログを残す。list.csvは追加で調査をするたびに更新する。
  • Deep Research的にライターが依頼した調査内容をまとめる
• ライターは知りたいことを追加で調査依頼できる。また、以降の小見出し作成、執筆、タイトル決定、レビュープロセスにおいても追加で調査依頼することができる。

小見出し作成

• ライターが依頼すると、エージェントはIssueの情報とこれまでの調査結果をもとに小見出しを作成。小見出しは当該記事専用のディレクトリ内にてheadings.csvとして作成する。csvには小見出しのタイトル、記事全体の位置付け、大まかな文字数などの情報を残す。エージェントはライターの依頼内容と作成されたcsvファイルをgit commit。
• ライターが評価し、必要であれば修正依頼をする。修正のたびにheadings.csvをアップデートする。エージェントはライターの修正依頼内容と更新したcsvファイルをgit commit。
• 最後の微修正はライターが直接ファイルを編集しても良い。
  • ライターは小見出しを作成終わったら、作成完了の旨をエージェントに伝える。エージェントはライターが最終的にマニュアルで修正を加えた旨をgit messageに含め更新したcsvファイルをgit commit。

執筆

• ライターがエージェントに執筆を指示する。
  • エージェントは調査情報（referencesディレクトリ）と小見出し（headings.csv）をもとに本文をマークダウン形式で執筆する。
  • （図表が必要な場合はどのような図表が必要かわかりやすいメモを残しておく。図表は人間が後で埋める）
  • エージェントはライターの依頼内容と作成されたmdファイルをgit commit。
• ライターは記事内容を確認し、自身の意図とずれるところがあれば修正依頼を出す。
  • エージェントはライターの指示に従ってmdファイルを修正する。
  • エージェントはライターの修正依頼内容と更新されたmdファイルをgit commit。
• 最後の微修正はライターが行っても良い
  • ライターは執筆が終了したら、完了の旨をエージェントに伝える。エージェントはライターが最終的にマニュアルで修正を加えた旨をgit messageに含め更新したmdファイルをgit commit。

タイトル決定

• ライターがエージェントにタイトル案出しを指示する
  • エージェント⁨⁩はIssue内容、本文をもとにタイトルの案をtitles.csvに作成する。csvにはタイトル案、読者が受ける印象、おすすめの理由、おすすめしない理由を記載する。
  • エージェントはライターのタイトル案として作成したcsvファイルをgit commit。
• ライターはタイトル候補が気に食わなければさらにエージェントにタイトル案出しを指示できる
  • エージェントはライターの指示に従ってcsvファイルを修正する。
  • エージェントはライターの追加依頼内容と更新されたcsvファイルをgit commit。
• ライターはcsvのタイトル案を選択する、あるいはそれらを元に自分でタイトルを考え、エージェントにタイトル決定の旨を伝える。

プレビュー

• ライターはエージェントにプレビューフェーズへの移行を指示する。
• エージェントはライターが最終決定したタイトル、小見出し、本文、添付画像を合成し、ブログ記事用のフォーマットに変換。
• ローカルでブログを立ち上げる、あるいは本番環境のブログにプレビューとしてデプロイ（ライターやエディターのみが閲覧できる）する。
• ライターはブラウザ経由で実際の見え方を確認する。
• 修正が必要であれば過去のフェーズに戻り作業をする。

レビュー

• ライターは執筆完了をエージェントに伝える。エージェントはブログ記事用のファイルをgit commit。PRを送る。PRではIssue内容を転記し、Issueと紐づける（PRをマージしたらIssueがクローズするようにする）。Issueにstatus/in-review　ラベルを付与する。
• エージェントがPRを作成したら、
  • 基本的な誤字脱字などはGitHub actionsで自動チェック。実際のブログ上での見栄えをプレビューモードでデプロイする。
  • SlackにてPR作成された旨をエディターに通知する。
• エディターがPRをチェック
  • 問題があればコメントを残し、エディターに修正を依頼する
  • エディターは必要に応じて調査、小見出し作成、執筆、タイトル決定のフェーズに戻って記事を修正する
• 問題が全て解消したらエディターはCTAを設定
• 全て完了したらエディターがPRをマージする
  • CI/CDにより自動で記事が公開される

アーキテクチャ提案（by ChatGPT o3）

プロンプト

以下の内容をもとに、まずは技術選定とアーキテクチャを考えます。
いくつかパターンを出して、それぞれの利点・欠点・どのような場合に推奨するかをまとめて提案してください
＝＝
{ここまでのメモ}

以下では 「AIエージェントが GitHub Issues とローカルファイルを主軸にワークフローを回す」という要件を満たしつつ、編集者やライターの快適さ・拡張性・デプロイ容易性などを考慮した技術スタック／アーキテクチャを3パターン提案します。いずれもMarkdown 原稿＋Gitを中核に据えることで LLM がローカル参照しやすい構造を保持し、人間は GUI も選べるようにしています。

パターン A

Git ベース SSG（Astro または Next.js 15）＋ GitHub Actions デプロイ

利点

• Markdown が単一ソース＝LLM が直接読み書き・要約しやすく、高速にファイル参照可。
• Astro は HTML ストリーミング無効化やセッション API など v5.7 の機能で柔軟性が高い (astro.build)。Next.js 15 は React 19 対応・Turbopack 高速ビルド等でスケールも安心 (nextjs.org)。
• GUI が不要なら最小構成。VS Code/Cursor だけで編集できる。

欠点

• ノンエンジニア向けの WYSIWYG 編集画面がない（画像貼付け時に Git 操作が必要）。
• 本番とプレビューを区別するために Preview URL や Deploy Preview の理解が必要。

推奨シーン

• 編集部全員が GitHub／Markdown に慣れている or エンジニア主体。
• 記事量が 1000 本未満規模でビルド時間が問題にならない場合。

パターン B

Git ベース SSG ＋ Decap CMS（旧 Netlify CMS）を Git リポジトリ直結 GUI として追加

利点

• コンテンツは Git に残るため LLM 参照容易かつ GUI で編集 できる（media library も自動フォルダ配置） (decapcms.org)。
• エディターは Git 操作を意識せず下書き→PR 作成まで完結できる（Decap が自動ブランチを切る）。
• 画像アップロードも /references フォルダ相当へ保存されるので要件と整合。

欠点

• Decap のリッチテキストが Markdown 互換とはいえ Front-matter などを自動整形するため、AI が出力する raw Markdown と衝突するケースがある。
• Netlify 以外にホストすると認証設定が手間。

推奨シーン

• 非エンジニア比率が高く、GUI 編集体験を優先 したい場合。
• 記事本数が中規模（〜数千）で Jamstack 運用を継続したい場合。

パターン C

ヘッドレス CMS（Strapi 5 Cloud or Self-Hosted）＋ Next.js 15 (ISR)

利点

• Strapi 5 では AI ベースのコンテンツモデル生成・履歴管理・プレビュー API が提供される (docs.strapi.io, strapi.io)。
• GUI が洗練され権限管理も豊富（RBAC）。大型メディアでも運用しやすい。
• Next.js ISR で「ビルド時間＝ページ数」問題を回避。

欠点

• GitHub Issues 起点のワークフローと CMS DB が二重管理になる → 連携プラグイン or Webhook 実装が必要。
• ローカルに PDF などを保存する要件は Strapi アップロード機能に置き換える／S3 連携など追加設計が必要。
• Self-host の場合は DB・サーバ保守コスト。

推奨シーン

• 将来的に 10,000 本超 の大規模メディアに拡大予定で、編集 GUI・権限管理・多言語対応が必須。
• LLM へのコンテキスト受け渡しを API 経由 JSON で統一したい場合。

共通事項と拡張アイデア

選定の指針まとめ

1. 編集者の技術リテラシーと GUI 必要度

   • CLI/Markdown で十分 → パターン A
   • GUI 必須だが Git ワークフローは維持 → パターン B
   • 完全 GUI＋API、権限管理重視 → パターン C

2. 将来の記事規模・ビルド時間

   • 〜千本規模なら Astro/Next.js SSG で OK。
   • 万本規模なら Next.js ISR や Strapi の Webhook による部分再生成が安全。

3. LLM との密結合レベル

   • ファイル直接編集で完結 → Git ベース。
   • RAG 用に API/DB で構造化取得したい → Headless CMS。

上記を参考に、編集部のスキルセットと今後のスケール計画を踏まえて最適なパターンを選択してください。

アーキテクチャ提案 (by Claude Opus 4)

プロンプト

以下の内容をもとに、まずは技術選定とアーキテクチャを考えます。
いくつかパターンを出して、それぞれの利点・欠点・どのような場合に推奨するかをまとめて提案してください
＝＝
{ここまでのメモ}

AI駆動型オウンドメディアのための技術選定とアーキテクチャパターンを3つ提案します。

パターン1: Git中心型アーキテクチャ

構成

• コアリポジトリ: GitHub（記事管理、Issue管理、PR/レビュー）
• ローカル開発環境: VS Code/Cursor + Git
• 記事フォーマット: Markdown + フロントマター
• 画像管理: Git LFS または専用画像フォルダ
• プレビュー/公開:
  • 静的サイトジェネレータ（Next.js/Gatsby/Hugo）
  • Vercel/Netlify でのプレビューデプロイ
• エージェント統合: GitHub API + ローカルファイルシステムアクセス

利点

• エージェントがファイルシステムと Git を直接操作可能
• バージョン管理が完全で、変更履歴が追跡しやすい
• GitHub Actions による自動化が容易
• エンジニアにとって親和性が高い
• プレビューURLが PR ごとに自動生成可能

欠点

• 非エンジニアには Git 操作のハードルが高い
• 画像アップロードが若干面倒（Git LFS の設定など）
• リアルタイムコラボレーションには不向き

推奨される場合

• チームメンバーが技術的スキルを持っている
• 厳密なバージョン管理と変更履歴が重要
• エージェントの自動化を最大限活用したい

パターン2: ヘッドレスCMS＋Git ハイブリッド型

構成

• コンテンツ管理: Strapi/Directus などのヘッドレス CMS
• タスク管理: GitHub Issues
• ローカル作業環境: Obsidian/Typora（Markdown エディタ）
• 同期システム: カスタムスクリプトで CMS ⇔ Git を同期
• プレビュー/公開: Next.js + CMS API
• エージェント統合: CMS API + GitHub API + ローカルファイル

利点

• GUI エディタで画像のドラッグ&ドロップが可能
• 非エンジニアも CMS 経由で記事編集可能
• エージェントは API 経由でコンテンツ操作可能
• プレビュー機能が充実

欠点

• システムが複雑になる（同期処理が必要）
• CMS と Git の状態管理が二重になる
• 初期構築コストが高い

推奨される場合

• エンジニアと非エンジニアが混在するチーム
• 将来的に外部ライターの参加も想定
• リッチなエディタ体験が必要

パターン3: ローカルファースト型

構成

• ローカル記事管理: 専用フォルダ構造（YYYY-MM-DD-title/）
• エディタ: Obsidian + Git プラグイン
• タスク管理: GitHub Issues（API 経由で同期）
• 画像管理: ローカルフォルダ + 自動リネーム
• 同期/公開: カスタムCLIツール → GitHub → SSG
• エージェント統合: ファイルシステム直接アクセス

利点

• エージェントが最も操作しやすい（ローカルファイル直接操作）
• Obsidian で画像の貼り付けが簡単
• オフラインでも作業可能
• フォルダ構造で記事と参考資料を一元管理

欠点

• 複数人での同時編集が困難
• ローカル環境のセットアップが必要
• バックアップ戦略が重要

推奨される場合

• 少人数チームでの運用
• エージェントの効率を最優先
• 調査資料と記事を密接に管理したい

推奨アーキテクチャ

要件を考慮すると、パターン3（ローカルファースト型）をベースに、パターン1の要素を組み合わせた構成を推奨します：

具体的な技術スタック

- エディタ: Obsidian（画像貼り付け対応、プラグイン豊富）
- バージョン管理: Git + GitHub
- タスク管理: GitHub Issues
- ローカル構造:
  articles/
    2024-01-15-ai-science-intro/
      draft.md
      headings.csv
      titles.csv
      references/
        paper1.pdf
        paper2.pdf
        list.csv
      images/
        fig1.png
        fig2.png
- 公開システム: Next.js + MDX
- デプロイ: Vercel（プレビュー）+ 本番環境
- エージェント: ローカルファイルAPI + GitHub API

この構成により、エージェントの操作性を最大化しつつ、人間にも使いやすい環境を実現できます。

提案へのコメント

• 非エンジニアのライターがCursorのみで作業することの難易度
  • すでに非エンジニアにCursorを用いた調査、執筆を試してもらっているが結構できそう
    • ただしN=1（東大修士卒）。知的好奇心、トライアンドエラー耐性は最高レベル。
    • ライターの採用要件が難しくなりそうだが、テーマがAI for Scienceなので元々採用候補の要件に「科学研究に従事した経歴」と「AIへの関心」が入っており、これらと通じるところがあると思われる。許容可能。
  • CMSのエディタ機能を使うとgitで補足できない編集が多発し、崩壊する未来が見える
    • 記事材料（参考文献、画像、本文）から公開用の記事を1つの記事ファイル（HTLMを想定しているが、要件が満たされるならなんでも良い）として作成。
    • そのファイルをプレビュー。修正があれば記事ファイルを直接編集、という形にしたい。ライターが直接HTMLを編集するのは、難易度や不正なフォーマットになることを加味して避けたい。記事材料から記事ファイルを作成する際は機械的な変換のみで行えることとし、プレビューを閲覧して修正したい場合は常に記事材料を修正することを徹底したい（修正後記事ファイルを再作成し、再度プレビューという流れ）。

アーキテクチャ決定 (by ChatGPT o3-pro)

プロンプト

以下の内容をもとに、技術選定とアーキテクチャを考えています。
===
{ここまでのメモ}
===

2名のエンジニアから以下の提案がありました。
===
{ChatGPT o3の提案}
===

===
{Claude Opus 4の提案}
===

それに対しての私の意見は以下の通りです。
===
{上記 提案へのコメント}
===

上記を総合的に判断し、アーキテクチャ・技術選定を決定してください。
フレームワークを決定する際には当該フレームワークの現時点での流行度合い、競合となるような新興プロダクトがないか調査の上判断してください。

決定：“Git × Astro 5” を中核にしたローカル‑ファースト Jamstack アーキテクチャ（拡張オプション付き）

1. 採用スタック概要

ポイント：GUI CMS を排除し Markdown ローカル単一ソース を徹底することで、
「記事材料を直すと即再生成→プレビュー」のシンプルな体験を保証。

2. フレームワーク選定根拠

結論

• Astro は “コンテンツ専用” の軽量 SSG、React ランタイムを抱えないため Build→Preview が高速。
• ライターが Cursor で直接 Markdown を扱えるため CMS 由来の破損リスクが無い。
• 規模が 5,000 本 を超えた場合のみ、ISR を持つ Next.js 15 への移行パスを残す。

3. 脅威・競合製品ウォッチ

月 1 回のスプリントで上記 OSS の動向をエージェントが Self‑Check し、移行判断を自動レポートする運用を推奨。

4. 詳細アーキテクチャ

📦 repo-root
├─ .github/workflows/ci.yml        # Astro build → Vercel deploy
├─ agents/                         # Issue/Bot スクリプト (Python/TS)
├─ articles/
│   └─ 2025-06-22-ai-protein/
│       ├─ draft.md                # 本文 (MDX)
│       ├─ headings.csv
│       ├─ titles.csv
│       ├─ references/
│       │   ├─ list.csv
│       │   └─ *.pdf
│       └─ images/
│           └─ *.png
└─ src/pages/[slug].astro          # MDX → HTML テンプレート

1. Issue → ブランチ作成
   Copilot Agent が git switch -c article/123-protein を実行し記事ディレクトリを scaffold。

2. 調査
   agent が PDF を references/ へ保存、list.csv にメタ追記。

3. 執筆
   headings.csv & draft.md を生成 → PR。

4. CI

   • astro build で静的 HTML + assets
   • Vercel Preview URL を PR コメントに自動貼付。

5. レビュー → マージ で本番 deploy。

6. RAG 検索用 Embedding（オプション）
   GitHub Actions 後段で references/*.pdf を LanceDB にローカル格納し、次回執筆フェーズのコンテキストに利用。

5. スケール＆将来拡張

6. リスク & 対応

7. まとめ

• 最小構成でも “AI と人が同じフォルダを見ている” ため、RAG 連携・自動コミット・プレビューが最短経路。
• Astro 5 は 軽量・高速・急伸 という現在の最適解。大規模化や GUI 要件が現れた時でも Next.js 15／TinaCMS／Strapi 5 へスムーズにピボット可能な拡張余地を確保した。
• これにより 「参考資料 → Markdown → 自動 HTML → プレビュー」 の純粋なループが保たれ、編集フローの破綻を防ぐ。

Go‑Live 手順：リポジトリ初期化 → Astro テンプレート (npm create astro@latest) →
GitHub Actions & Vercel 接続 → Copilot Agent セットアップ → ライター onboard。
これで 最短 1 週間 で媒体を立ち上げ可能です。

用語解説 (by ChatGPT o3-pro)

プロンプト

ありがとうございます。
理解を深めるために専門用語、サービス名についてそれぞれ初心者向けに解説してください。

以下では、先ほどの提案に登場した 主要な専門用語・サービス名 を五つのカテゴリに分け、「一言で言うと → もう少し詳しく」 の 2 段階でやさしく解説します。
（★はとくに重要な用語です）

1. コンテンツとバージョン管理

2. サイト生成とホスティング

3. コンテンツ編集フォーマット

4. AI・検索関連

5. CMS と GUI ツール

使い方イメージを 30 秒で

1. ライターは Cursor で Markdown を編集 → GitHub にプッシュ
2. GitHub Actions が Astro で HTML を自動生成 → Vercel へアップ
3. プレビュー URL を開いて確認。OK なら PR をマージ → 本番公開
4. 後から AI（Copilot Agent）が資料を追加したら、再プッシュで同じ流れを再実行

難しく感じる言葉は 「丸ごとお任せサービス」か「フォーマット／仕組みの名前」 のどちらかと覚えると整理しやすいです。

知らないことをいろいろ教えてもらう: Reactランタイムについて（by Claude Opus 4）

わかりやすく説明しますね！

「Reactランタイムを抱えない」とは？

従来のReactサイト（Next.jsなど）

// ページが表示される時の動作
1. HTMLが読み込まれる
2. 大きなReact本体（約45KB）が読み込まれる ← これがランタイム
3. すべてのコンポーネントのJavaScriptが読み込まれる
4. Reactがページ全体を「動的に」再構築する
5. やっとインタラクティブになる

ページを見るだけでも、Reactという「エンジン」を丸ごとダウンロードする必要がある

Astroの場合

// ページが表示される時の動作
1. HTMLが読み込まれる
2. 必要な部分だけ小さなJavaScriptが読み込まれる
3. 完了！

// Reactは「ビルド時」だけ使って、配信時は不要

具体例で理解する

記事ページの例

Next.js（従来）の場合

// 記事ページのコンポーネント
export default function Article({ title, content }) {
  return (
    <article>
      <h1>{title}</h1>
      <div>{content}</div>
      <ShareButton />  {/* インタラクティブ */}
    </article>
  )
}

// 配信されるもの：
// - HTML
// - React本体（45KB）
// - このコンポーネントのJS
// - ShareButtonのJS
// → 合計: 100KB以上のJavaScript

Astroの場合

---
// Article.astro
const { title, content } = Astro.props;
---

<article>
  <h1>{title}</h1>
  <div>{content}</div>
  <ShareButton client:load />  {/* これだけインタラクティブ */}
</article>

// 配信されるもの：
// - 純粋なHTML
// - ShareButtonの最小限のJS（5KB程度）
// → 合計: 5KBのJavaScript

「アイランドアーキテクチャ」

Astroが採用している考え方です：

静的な海（HTML）の中に、動的な島（JavaScript）が点在する

ページ全体
├── ヘッダー（静的HTML）
├── 記事本文（静的HTML）
├── シェアボタン（動的な島 🏝️）← ここだけJS
├── コメント欄（動的な島 🏝️）← ここだけJS
└── フッター（静的HTML）

パフォーマンスの違い

初期表示速度

Next.js: HTML → JS読込(45KB+) → React起動 → 表示完了
         └─────── 1〜2秒 ────────┘

Astro:   HTML → 表示完了 → 必要な部分だけJS
         └ 0.1秒 ┘

ビルド速度の違い

Next.js: すべてのページでReact処理が必要
         → 1000記事で5〜10分

Astro:   単純なHTML変換がメイン
         → 1000記事で1〜2分

実際のコード比較

インタラクティブなCTAボタン

Next.jsでの実装

// すべてがJavaScriptとして配信される
import { useState } from 'react';

export default function CTASection() {
  const [email, setEmail] = useState('');
  
  return (
    <section>
      <h2>ニュースレター登録</h2>
      <p>最新情報をお届けします</p>
      <input 
        value={email}
        onChange={(e) => setEmail(e.target.value)}
      />
      <button>登録</button>
    </section>
  );
}

Astroでの実装

---
// CTASection.astro
---
<section>
  <h2>ニュースレター登録</h2>
  <p>最新情報をお届けします</p>
  <!-- ↓ この部分だけReactを使う -->
  <EmailForm client:visible />
</section>

<!-- 結果：
- 見出しと説明文は純粋なHTML
- フォーム部分だけJavaScript
-->

まとめ：なぜ速いのか

1. 不要なJavaScriptを削除

   • 見るだけのコンテンツにJSは不要
   • 必要な部分だけJSを使う

2. ビルドが単純

   • 複雑なReact処理が不要
   • HTML生成に特化

3. 配信サイズが小さい

   • React本体（45KB）が不要
   • ページサイズが1/10以下になることも

オウンドメディアのように「読むことがメイン」のサイトでは、Astroのアプローチが圧倒的に効率的です！

知らないことをいろいろ教えてもらう: MDXについて（by Claude Opus 4）

MDX（エムディーエックス）とは？

MDXは「Markdown + JSX」の組み合わせです。通常のMarkdownに、Reactコンポーネントを埋め込めるようにした拡張形式です。

通常のMarkdown

# 記事タイトル

これは普通の文章です。

![画像](image.jpg)

MDX

# 記事タイトル

これは普通の文章です。

<FloatingCTA title="今すぐダウンロード" />

インタラクティブなグラフも埋め込めます：

<InteractiveChart data={salesData} />

MDXでできること

1. インタラクティブな要素を記事に埋め込む

# AIの進化を体験しよう

以下のデモで、実際にAIの画像認識を試せます：

<AIImageRecognitionDemo />

すごいでしょう？このように、記事の中で実際に動くデモを提供できます。

2. 動的なデータ表示

# 最新の研究論文数

現在、AI for Science分野の論文数は：

<PaperCount category="ai-science" realtime={true} />

件です。（リアルタイム更新）

3. 条件付き表示

import { isPremiumUser } from '../utils/auth'

# 詳細な分析レポート

基本的な情報はこちらです。

{isPremiumUser() ? (
  <PremiumContent>
    ## 有料会員限定コンテンツ
    詳細な分析データ...
  </PremiumContent>
) : (
  <CTABox>
    この先は有料会員限定です。
    <SignUpButton />
  </CTABox>
)}

Astro + MDXの利点

1. 記事は基本Markdownで書ける

エンジニアでなくても、通常のMarkdown記法で執筆可能：

# 見出し
**太字**や*斜体*も普通に使えます。

- リスト1
- リスト2

普通のMarkdownとして書いて、必要な時だけコンポーネントを使う。

2. 必要な部分だけインタラクティブに

# 機械学習の基礎

## ニューラルネットワークとは

通常の説明文...

実際に動かしてみましょう：

<NeuralNetworkPlayground />

このように、説明と実践を組み合わせられます。

3. CTAの柔軟な配置

# ホワイトペーパー：AI活用ガイド

## はじめに

AI活用の重要性について...

<InArticleCTA 
  type="whitepaper"
  title="完全版をダウンロード"
  position="after-intro"
/>

## 具体的な活用方法

詳細な説明...

実際の使用例

ファイル構造

articles/
  2024-01-15-ai-science.mdx
  components/
    FloatingCTA.jsx
    InteractiveChart.jsx

MDXファイルの中身

---
title: "AIが変える科学研究の未来"
date: 2024-01-15
author: "山田太郎"
---

import FloatingCTA from './components/FloatingCTA'
import ResearchTimeline from './components/ResearchTimeline'

# AIが変える科学研究の未来

最新の研究によると...

<ResearchTimeline 
  startYear={2020} 
  endYear={2024}
  highlights={['GPT-4', 'AlphaFold3']}
/>

## 詳細な分析

ここから本格的な内容に入ります。

<FloatingCTA 
  trigger="scroll"
  threshold={70}
  content="詳細レポートをダウンロード"
/>

MDXの利点まとめ

1. 執筆は簡単 - 基本はMarkdown
2. 拡張性が高い - 必要に応じてコンポーネント追加
3. AIエージェントも扱いやすい - テキストベースなので
4. インタラクティブ - 読者体験を向上
5. メンテナンスしやすい - コンポーネントは再利用可能

オウンドメディアで「ただ読むだけ」から「体験する記事」へとレベルアップできるのがMDXの魅力です！

仕様書作成 (by ChatGPT o3-pro)

プロンプト

いいですね。あなたの提案アーキテクチャを採用します。

ここまでの情報を単一の仕様書にまとめてください。
それを元にCursorと実装に入ります。

その後何度か修正指示。

AI for Science オウンドメディア

実装仕様書 v1.3 （2025‑06‑22 改訂）

0. 概要

1. 採用技術スタック（バージョン指定）

2. 用語解説（初心者向け）

3. ディレクトリ & 命名規約

repo-root/
├─ .github/workflows/ci.yml
├─ agents/                 # AI エージェント
├─ taxonomy/
│   └─ tags.csv            # 編集部公式タグ
├─ components/
│   ├─ HubspotCTA.tsx
│   └─ ShareButtons.tsx
├─ articles/
│   └─ YYYY-MM-DD-slug/
│       ├─ draft.md
│       ├─ headings.csv
│       ├─ titles.csv
│       ├─ references/
│       │   ├─ list.csv
│       │   └─ *.{pdf,html,docx,pptx,xlsx,png,jpg}
│       └─ images/*.png
└─ src/pages/[slug].astro

4. CSV & Front‑Matter

4.1 taxonomy/tags.csv（編集部公式タグ）

タグ追加・改廃は編集者のみが別 PR で行い、CI が重複・空タグを拒否。

4.2 headings.csv・references/list.csv・titles.csv

（構造は v1.2 と同じ。references は 複数拡張子 を許容）

4.3 各記事 draft.md Front‑Matter

---
title: "決定済みタイトル"
tags: ["protein-design", "deep-learning"]   # taxonomy/tags.csv に存在するものだけ
cta: HubspotCTA               # 省略可：components/ に一致
share: ShareButtons           # 省略可
---

5. 記事管理用 Issue テンプレ

---
target_keyword: "protein design ai"
monthly_search_volume: 1200
competitiveness: "medium"
recommended_length: 3000
expected_reader: "分子生物学を専攻する大学院生"
candidate_tags: ["protein-design", "deep-learning"]  # taxonomy/tags.csv から選択
proposed_headings:
  - "AI がもたらすタンパク質設計革命"
  - "言語モデル応用の仕組み"
---

6. フェーズ & ラベル遷移（タグ工程を統合）

タグは メタデータフェーズ でタイトルと同時に決定・確定し、Front‑Matter に書き込まれる。
CI が tags: の値を taxonomy/tags.csv と照合し不一致なら失敗。

7. React コンポーネント利用規定

8. CI/CD 主要ジョブ

1. Lint & Schema

   • markdownlint・csv‑schema
   • Front‑Matter tags: を taxonomy/tags.csv に対し検証

2. Preview Build（pull_request）

   • astro build --site https://preview-url
   • Vercel Preview→URL を PR コメント

3. Production Deploy（push main）

   • astro build → Vercel --prod

9. ローカル開発フロー要約

gh issue checkout 123                # ブランチ作成
make agent RESEARCH ISSUE=123 ...
make agent HEADINGS ISSUE=123
make agent METADATA ISSUE=123        # タイトル＋タグ
make agent DRAFT ISSUE=123
gh pr ready                          # プレビュー

10. スケール計画（記事数基準）

11. リスク管理（抜粋）

12. マイルストーン（更新版）

本書を SPEC.md として main にコミットし、Cursor で実装を開始してください。

Claude Code使って実装してみよう。流行りだし。
Claude CodeのDocsをチェック。脇道にそれる。