はじめに#
正直に告白すると、私はモノづくりが大好きなのですが、それに伴うお決まりの定型作業（ボイラープレート）まで好きかというと、必ずしもそうではありません。新しい記事のアイデアは常にたくさんあるものの、構成を組み立て、自分の編集基準を満たしているか確認し、適切なトーンに仕上げるというプロセスは、時に重荷に感じられることがあります。この記事は、ある技術仕様を深く掘り下げたことをきっかけに、執筆プロセスに心地よい構造化をもたらすMCPサーバー、Speedgrapher を構築することになった物語です。
Speedgrapher への道のりは、前回の記事「GoDoctorの構築：Gemini CLIとGoでMCPサーバーを作成する」を公開した直後に始まりました。その記事では、Model Context Protocol (MCP) によってAIエージェントがいかにツールを利用できるようになるかという点に特化して解説しました。公開後、私はMCP仕様を改めてじっくり読み直してみました。そこで、以前は見落としていた小さな記述が目に留まりました。MCPは tools だけでなく、prompts や resources も明示的に定義していたのです。頭の中で電球が点灯しました（ひらめきました）。メモやローカルファイル、GitHubリポジトリのあちこちに散らばっていたプロンプト集を、まったく同じプロトコルを使ってパッケージ化し、ポータブルに持ち運べるのではないかと気づいたのです。
実に幸運な偶然でした。私がプロンプトサーバーの構想を練っていたその日、Gemini CLIチームが、MCPサーバーが公開するプロンプトをネイティブのスラッシュコマンドとして利用可能にする新機能を発表したのです。これにより、ポータブルなバックエンドツールキットという私のアイデアが、ターミナル上で直接動くファーストクラスで使いやすいUIを手に入れられることになりました。Speedgrapher のコンセプトは一気に明確になりました。シンプルなスラッシュコマンドとして呼び出せる、執筆ツールキットを束ねた専用MCPサーバーです。
Vibe Writing とは何か#
Speedgrapher を構築した技術的な道のりに飛び込む前に、「バイブライティング（vibe writing）」という言葉で私が何を意味しているのかを少し説明させてください。「バイブコーディング（vibe coding）」という言葉を耳にしたことがある方も多いでしょう。これは、自然言語のプロンプトを使ってAIを導きながらコードを生成させる、最近ますます一般的になってきた開発スタイルを指します。開発者が大所高所の方向性を定め、AIが定型コードや細かな実装を担うという、流れるような対話的アプローチです。
「Vibe writing」は、このアプローチを「言葉」の世界へと自然に拡張したものです。私にとってそれは、孤独な執筆作業を、AIパートナーとのダイナミックで協力的な対話へと変えることを意味します。文構造や文法、完璧な言い回し探しといった細部に足を取られることなく、伝えたい中心メッセージ、つまり生み出したい「バイブ（空気感・熱量）」に集中できるのです。私が最初の火種（大まかなアイデア、個人的な体験談、直面した厄介な課題など）を提示し、AIがそれを構造的で筋の通った物語へと形作る手助けをしてくれます。
この言葉を使ったのは私が最初ではありませんが、まだ生まれたばかりの新しい概念です。これはコンテンツ制作へのアプローチにおける根本的なシフトであり、完全な手作業から人間とAIの協調関係への移行を表しています。
まずはシンプルに：俳句ジェネレーター#
どんな優れた技術探求も、まずは「Hello, World」から始まります。Speedgrapher における私の「Hello, World」は俳句（Haiku）でした。プロンプトをスラッシュコマンドとして公開できることを実証するための、手軽でリスクの少ない方法が必要だったのです。AIに詩を詠んでもらうこと以上に手軽な検証があるでしょうか？
最初の試みはあまりに素朴なものでした。--theme 引数を取る /haiku プロンプトを作成し、プロンプト自体も "generate a haiku based on the theme %s" という単純なものでした。Gemini CLIを起動し、Speedgrapherプロジェクトをコンテキストとして読み込ませた状態で、こう入力しました。
/haiku --theme=flowers
その結果返ってきたのは……詩ではありませんでした。モデルはプロジェクト内のGoコードを見て、私のリクエストを「Speedgrapherに俳句機能を追加せよ」という指示だと解釈してしまったのです。そしておもむろにGoファイルの編集計画を立て始めました。私は慌てて ESC キーを押して処理を中断し、作戦を練り直すことにしました。
この経験は、プロンプトエンジニアリングにおける極めて重要な原則を思い出させてくれました。「曖昧さ（ambiguity）」と「コンテキスト（context）」のバランスを取る必要性です。私が作成するプロンプトの多くでは、モデルが柔軟に推論して情報を補完できるように、あえてある程度の曖昧さを残しています。たとえば /review プロンプトは、単に「私たちが作業してきた記事をレビューしてください」とだけ指示しています。DRAFT.md のような具体的なファイル名は指定していません。対話型ワークフローにおいて、この曖昧さは強力な武器になります。モデルは厳密で固定的なファイルパスがなくても、直近のやり取りから対象のテキストを自律的に特定できるからです。
しかし俳句の場合、その曖昧さに適切な制約がありませんでした。メインのコンテキストがGoプロジェクトだったため、モデルは論理的ではあるものの意図とは異なる結論――「コードを変更したいのだろう」――を導き出してしまったわけです。モデルが間違っていたわけではなく、与えられた情報から妥当な推論をしたに過ぎません。今回はコードと無関係な極めて具体的なアウトプットを求めていたため、意図を明確にするコンテキストを与えて曖昧さを排除する必要がありました。
試行錯誤を重ねた結果、最終的に以下のプロンプトに落ち着きました。
// 俳句コマンド用として正常に動作した最終プロンプト
prompt = fmt.Sprintf("The user wants to have some fun and has requested a haiku about the following topic: %s", topic)これが意図を伝える最善の表現かどうかはわかりませんが、目的には見事に合致し、モデルはその後一貫して俳句を詠んでくれるようになりました。コアコンセプトの実証が完了したため、より実践的なプロンプトの構築へと駒を進めました。
執筆ツールキットの構築#
俳句の実験によってコアコンセプトの正しさが証明されたので、より実践的な応用へと進みました。当時の私の GEMINI.md ファイルは、記事のレビュー、翻訳、アウトライン作成といった便利なプロンプトの宝庫になっていたものの、ポータビリティがありませんでした。特定のリポジトリに紐づいていたため、新しいプロジェクトを始めるたびにコピーし忘れることがよくあったのです。これらのツールをポータブルにするための次なる論理的一歩が、MCPサーバー化でした。
まずは特によく使っていた3つのプロンプト―― interview、review、localize ――を Speedgrapher に移植することから着手しました。これらのプロンプトの核となるのは「編集ガイドライン」です。たとえばローカリゼーションのガイドラインには「技術用語は安易に翻訳しない」というルールを含めており、当ブログがサポートする3つの言語間での一貫性を担保しています。このような「コードとしての編集ガイドライン（Editorial Guidelines as Code）」を定義するアプローチは、コードに対するリンターのように、一定の文体やクオリティを維持する構造化された仕組みを築く有効な方法です。
Speedgrapher に含まれるプロンプトはすべて Gemini の支援を受けて作成しましたが、review プロンプトについては少し異なるアプローチを取りました。モデルに私の過去の記事を分析させ、私の執筆スタイルに基づいた編集ガイドラインの策定を指示したのです。生成された初稿は非常に完成度が高いものでしたが、今でも継続的に改善を続けています。
以下は、GitHubの Speedgrapher ソースコードから直接埋め込んだプロンプトの最新版です。
"context"
"errors"
"os"
"github.com/modelcontextprotocol/go-sdk/mcp"
)
const reviewPrompt = `
You are a professional editor for a technical blog.
Your task is to review an article and ensure it meets our editorial guidelines.
Provide constructive feedback to the author on how to improve it.主要なプロンプトが揃ったところで、執筆ワークフローにおける他の重要なステップの自動化に取り掛かることにしました。
リーダビリティの追求#
テクニカルライターとしての最大の課題は、「明快さ（clarity）」と「深み・複雑さ（complexity）」の絶妙なスイートスポットを見つけることです。文章が単純すぎると幼稚に感じられ、複雑すぎると途端に読みにくくなります。リーダビリティとは単に平易にすることではなく、読者を引き込み、知的な刺激を与えることでもあるのです。
ありがたいことに、リーダビリティは数値として測定できます。完璧な指標は存在しないものの、Gunning Fog Index（ガンニング・フォグ・インデックス） は基準値を把握するための優れた指標です。これは、文章を初見で理解するために何年間の正規教育が必要かを推定する可読性テストです。たとえばスコア「12」は、米国の高校3年生（シニア）相当の読解レベルであることを示します。
インデックスは、以下のアルゴリズムに基づいて算出されます。
- 100語以上のテキストセクションを抽出する
- 1文あたりの平均単語数（平均文長）を算出する
- 「難解な単語（3音節以上の単語）」の数を数える
- 平均文長に、難解な単語の割合（パーセンテージ）を加算する
- その結果に 0.4 を掛ける
数学的な数式で表すと、このアルゴリズムは以下のようになります。
\[ 0.4 \times \left[ \left( \frac{\text{words}}{\text{sentences}} \right) + 100 \left( \frac{\text{complex words}}{\text{words}} \right) \right] \]Fog Indexの本来の目的はテキストの理解に必要な「教育年数」を推定することですが、教育年数という枠組みで考えるのはあまり実用的ではないと感じたため、自分のニーズに合わせてカスタマイズすることにしました。まず、特殊な例外規則を無視して計算を単純化しました。このアルゴリズムで最も複雑（complex）な部分の一つは、何をもって単語が「複雑（complex）」であるかを定義する処理です（しゃれのようですが）。基本ルールでは3音節以上の単語を難解とみなしますが、-ing、-ed、-es などの特定の接尾辞を除外するといった例外ケースが存在します。
この例外処理は、実装時に思いのほか厄介な問題を引き起こしました。私にとって極端な厳密さは不要であり、シンプルさを優先して複雑度を多少過大評価する程度で十分でした。そこで、すべての例外ケースを排し、音節のカウントに関して2つの基本ルールのみを採用しました。1) 単語内の音節数は母音グループの数で推定する、2) 3音節以上の単語はすべて難解な単語とみなす（例外なし）。
また、教育年数から実用的なアプローチへと焦点を移した分類システムも作成しました。
| スコア | 分類 | 説明 |
|---|---|---|
| >= 22 | 難解すぎる（Unreadable） | ほとんどの読者にとって理解が困難 |
| 18-21 | 読みにくい（Hard to Read） | 専門家であってもかなりの読解労力を要する |
| 13-17 | 専門家向け（Professional） | 専門知識を持つ読者に最適 |
| 9-12 | 一般向け（General） | 多くの読者にとって明快で親しみやすい |
| < 9 | 平易すぎる（Simplistic） | 幼稚、あるいは単純すぎると受け取られる可能性がある |
カスタマイズした Gunning Fog Index を fog ツールとして実装した後の最後のステップは、使いやすいインターフェースを用意することでした。fog ツールを呼び出して結果をわかりやすいフォーマットで提示する /readability プロンプトを作成しました。これは、「単一機能に特化したツールを作り、それらを組み合わせてより強力で使いやすいワークフローを構築する」という Speedgrapher の設計指針に沿ったものです。
執筆ワークフローの自動化#
個々のプロンプトは有用でしたが、理想のワークフローを実現するには、まだ自動化すべきプロセスが多く残されていました。その後の数回のイテレーションを通じてプロンプトを実践投入し、プロセスの隙間を洗い出しながら、新しいプロンプトの追加や既存プロンプトの微調整を行いました。現在使用しているプロンプトは以下のとおりです。
メインフロー
/interview: 記事の素材を集めるために著者にインタビューを行います。通常、執筆セッションの起点となります。/outline: 現在のドラフト、コンセプト、またはインタビュー記録から構造化された構成案を生成します。/voice: 著者の文体やトーン（声）を分析し、生成される文章にその個性を反映させます。/expand: 作成中の構成案や下書きを、より詳細な記事へと肉付けして拡張します。hint引数を指定して、特定の段落やセクションを集中的に拡充することも可能です。/review: 執筆中の記事を編集ガイドラインに照らしてレビューします。/readability: Gunning Fog Index を用いて、直前に生成されたテキストの可読性を分析します。/localize: 執筆中の記事を指定した対象言語に翻訳・ローカライズします。/publish: 記事の最終版を公開用に書き出します。
オプション
/context: 後続のコマンドのために、現在執筆中の記事をコンテキストに読み込みます。必要に応じてモデルに現在のドラフトを「思い出させる」ために使用し、全文を対象とする/readabilityや/reviewなどのコマンドの前に実行することがよくあります。/reflect: 現在のセッションを分析し、執筆プロセスの改善点を提案します。プロンプトや編集ガイドラインを改良する際に役立ちます。
目指したのは、単なる便利なコマンドの集まりから、ひとつのアイデアを洗練された多言語記事へと導く、一本の合理化されたプロセスへと昇華させることでした。
以下の図は、私の執筆ワークフローを簡略化して表したものです。
flowchart TD
A[アイデア] -->|/interview| B[インタビュー記録]
B -->|/outline & /voice| C[構造化された構成案]
C -->|/expand| D[記事の初稿]
D -->|/review & /readability| E[推敲済みドラフト]
E -->|/localize| F[ローカライズ版]
F -->|/publish| G[公開された記事]
プロセスは、アイデアの核となるコンセプトを深掘りする /interview から始まります。得られたインタビュー記録は /outline によって構造化された計画へと変換され、/voice によって私自身の文体に合わせて調整されます。この土台ができあがったら、/expand でドラフトを書き進め、/review と /readability で推敲を重ねる反復ループに入ります。
記事が完成して承認されたら、/localize で他言語版を作成し、/publish で公開プロセスを完了します。さらにオプションの /reflect プロンプトを使えば、セッション全体を振り返って将来の改善メモを作成し、継続的な改善サイクルを回すことができます。
まとめ#
リンターやテストを使ってコードに規律と構造をもたらすのと同じように、クリエイティブなワークフローにもまったく同じ原則を適用できます。執筆プロセスには、自動化できる反復作業が無数に存在します。自分専用のプロンプトツールキットを構築することで、お決まりの定型作業から解放され、作品の核となるアイデアの探求に集中できるようになります。
これこそが Speedgrapher のようなツールの真価です。「バイブライティング（vibe writing）」は書き手を置き換えるものではなく、執筆プロセスを拡張・強化（オーグメント）するためのアプローチです。そこにMCPサーバーを組み込むことで、混沌としがちなワークフローに心地よい構造化をもたらし、ベストプラクティスを確実に遵守させることができます。これはあらゆるAI支援プロセスに共通して言えることです。自らのプロンプトを再利用可能でポータブルな資産として扱うことで、自身のワークフローとともに進化するシステムを作り上げ、創作の醍醐味に専念できるようになるのです。
今後の展望#
Speedgrapher をめぐる探求は、まだ始まったばかりです。現在のツールキットはテキスト処理に特化していますが、次の論理的なステップはマルチモーダルへの対応です。記事のヒーロー画像（アイキャッチ）を生成したり、テキストから洗練された図表を作成したり、レイアウトの最適化を提案するツールの統合を模索しています。執筆以外の雑多なタスクをツールキットに任せ、自分自身はコンテンツそのものの探求に集中できるようにすることが目標です。
参考リソース#
- Speedgrapher プロジェクト: 本記事で紹介したMCPサーバーのソースコード。
- GoDoctorの構築：Gemini CLIとGoでMCPサーバーを作成する: このプロジェクトの着想のきっかけとなった前回の記事。
- Model Context Protocol (MCP): MCPの公式ウェブサイト。
- Gemini CLI の公式アナウンス: カスタムスラッシュコマンド対応を発表した公式ブログ記事。
- Gunning Fog Index: 可読性測定アルゴリズム（Wikipedia記事）。
