はじめに#
告白することがあります。私は物を作るのが大好きですが、それに伴う定型的な作業が必ずしも好きというわけではありません。新しい記事のアイデアはたくさんありますが、それらを構成し、自分自身の編集基準を満たしていることを確認し、さらにはトーンを正しく設定するプロセスは、時には面倒に感じることがあります。これは、技術仕様を深く掘り下げたことが、私の執筆プロセスを支援するMCPサーバーであるSpeedgrapherを構築することにつながった物語です。
Speedgrapherへの旅は、前回の記事「Gemini CLIとGoでMCPサーバーを構築する方法」を公開した直後に始まりました。その投稿では、Model Context Protocol (MCP)がAIエージェントにツールの使用をどのように許可するかに完全に焦点を当てました。それを公開した後、私はMCP仕様をもう一度読み直しました。今回は、以前に見落としていた細部に目が留まりました。toolsに加えて、プロトコルはpromptsとresourcesも明示的に定義しています。ひらめきました。メモ、ファイル、GitHubリポジトリに散らばっていたプロンプトのコレクションを、まさに同じプロトコルを使用してパッケージ化し、ポータブルにできることに気づきました。
幸運な偶然にも、私がプロンプトサーバーのアイデアを探求していた同じ日に、Gemini CLIチームは、MCPサーバーによって公開されたプロンプトをネイティブのスラッシュコマンドとして利用可能にする新機能を発表しました。これは、ポータブルなバックエンドツールキットの私のアイデアが、ターミナルで直接、ファーストクラスでユーザーフレンドリーなインターフェースを持つことができることを意味しました。Speedgrapherのコンセプトは今や明確になりました。シンプルなスラッシュコマンドとして公開される、ライティングツールキットを収容する専用のMCPサーバーです。
Vibe Writingの説明#
Speedgrapherを構築する技術的な旅に飛び込む前に、「vibe writing」という言葉で私が何を意味するのかを説明する時間を少し取りたいと思います。おそらく「vibe coding」という言葉を耳にしたことがあるでしょう。これは、開発者が自然言語のプロンプトを使用してAIにコードを生成させるという、ますます一般的になっている慣行を表しています。これは、開発者が高レベルの方向性を設定し、AIが定型的な作業と実装の詳細を処理する、流動的で会話的なアプローチです。
「Vibe writing」は、この概念を言葉の世界に自然に拡張したものです。私にとって、それは書くという孤独な行為を、AIパートナーとのダイナミックで協力的な会話に変えることです。文の構造、文法、完璧な言葉を見つけることの仕組みにとらわれるのではなく、私が作成したい「vibe」、つまり中心的なメッセージに集中できます。私は最初の火花、つまり大まかなアイデア、個人的な話、イライラする問題を提供し、AIがそれを構造化された一貫性のある物語に形作るのを手伝ってくれます。
私がこの言葉を最初に使用したわけではありませんが、それはまだ新しい概念です。それは、コンテンツ作成へのアプローチ方法における根本的な変化を表しており、純粋に手動のプロセスから人間とAIのパートナーシップへと移行しています。
シンプルな始まり：俳句ジェネレーター#
すべての優れた技術的な旅は、「ハロー、ワールド」から始まります。Speedgrapherにとって、私の「ハロー、ワールド」は俳句でした。プロンプトをスラッシュコマンドとして公開できることを証明するための、シンプルでリスクの低い方法が必要でした。AIに詩を書かせることよりシンプルなことがあるでしょうか？
私の最初の試みは単純でした。--theme引数を取る/haikuプロンプトを作成しました。プロンプト自体はシンプルでした：「テーマ%sに基づいて俳句を生成する」。Gemini CLIを起動し、Speedgrapherプロジェクトをコンテキストとしてロードし、次のように入力しました。
/haiku --theme=flowers
結果は…詩ではありませんでした。モデルは、私のプロジェクトのGoコードを見て、私のリクエストをSpeedgrapherに俳句機能を追加するという指示として解釈しました。Goファイルの編集を計画し始めました。戦略を再考する必要があったため、すぐにESCを押して中止しました。
この経験は、プロンプトエンジニアリングにおける中心的な原則、つまり曖昧さとコンテキストのバランスをとる必要性を強く思い出させるものでした。私のプロンプトの多くでは、モデルに推論し、情報を推測する柔軟性を与えるために、意図的にある程度の曖昧さを使用しています。たとえば、私の/reviewプロンプトは単に「作業中の記事をレビューする」と述べています。DRAFT.mdのようなファイル名は指定していません。この曖昧さは、モデルが厳密で明示的なファイルパスを必要とせずに、最近のやり取りから関連するテキストを識別できるため、会話型のワークフローでは強力なツールです。
しかし、俳句の場合、曖昧さは制約されていませんでした。主なコンテキストはGoプロジェクトであり、それがモデルを論理的ではあるが誤った結論、つまりコードを変更したいという結論に導きました。それは間違っていませんでした。それは単に合理的な推論をしていただけです。非常に具体的でコードに関連しない結果を望んでいたため、この場合の私のタスクは、私の意図に対してはるかに明確なコンテキストを提供することによって曖昧さを減らすことでした。
さらに数回試した後、次のプロンプトにたどり着きました。
// 俳句コマンドの最終的で機能するプロンプト。
prompt = fmt.Sprintf("ユーザーは少し楽しみたいと思っており、次のトピックに関する俳句をリクエストしました：%s", topic)
これが私の意図を表現する最良の方法であるかどうかはわかりませんが、それは私の目的に合っており、モデルはその後一貫して俳句を生成しました。中心的な概念が証明されたので、より実用的なプロンプトを構築する準備ができました。
ライターのツールキットの構築#
俳句の実験は、中心的な概念が健全であることを確認したので、より実用的なアプリケーションに移りました。私のGEMINI.mdファイルは、記事のレビュー、翻訳、アウトライン作成などのタスクのための便利ですがポータブルではないプロンプトのコレクションになっていました。それらは特定のプロジェクトに結び付けられていたため、新しいプロジェクトにコピーするのを忘れることがよくありました。MCPサーバーは、これらのツールをポータブルにするための論理的な次のステップでした。
私は、最もよく使用する3つのプロンプト、interview、review、localizeをSpeedgrapherに移行することから始めました。これらのプロンプトの中核は、「編集ガイドライン」のセットです。たとえば、ローカリゼーションガイドラインには、技術用語を翻訳しないというルールが含まれており、これにより、私のブログがサポートする3つの言語間で一貫性を確保できます。この「コードとしての編集ガイドライン」を作成するというアプローチは、リンターがコードに対して行うのと同様に、一貫した声と品質を維持する構造化されたシステムを構築する方法です。
SpeedgrapherのすべてのプロンプトはGeminiの助けを借りて生成されましたが、reviewプロンプトについては、少し異なるアプローチを取りました。モデルに私の過去の記事を分析させ、私の執筆スタイルに基づいて編集ガイドラインのセットを生成するように依頼しました。結果は堅実な初稿でしたが、それは私が常に改良しているプロンプトです。
これが、GitHubのSpeedgrapherソースコードから直接埋め込まれたプロンプトの現在のバージョンです。
## Editorial Guidelines
### Core Philosophy
- **Is it a personal story?** Every article must be a personal story about a technical journey. It's not just a tutorial; it's a narrative that shares the "why" and the "how," including the struggles, the "aha!" moments, and the hard-won lessons.
- **Is it helpful?** The goal is to be cozy, helpful, and relatable.
### Tone of Voice
- **Is it personal?** The article should start with a personal story or a relatable frustration to connect with the reader on a human level.
- **Is it honest?** The article must not present a sanitized, perfect process. It must highlight the "pain and payoff" by talking about cryptic error messages, flawed initial prompts, and the hours of trial-and-error. These struggles contain the most valuable lessons.
- **Is it professional?** The tone must be that of an experienced peer sharing knowledge. It must avoid overly simplistic or patronizing language.
- **Does it empower the reader?** The article must present information objectively and avoid subjective judgments (e.g., calling a protocol "simple"). It should allow the reader to form their own opinions based on the facts and the story.主要なプロンプトが配置されたので、私の仕事の他の重要な部分を自動化する作業に取り掛かる時が来ました。
読みやすさは重要#
テクニカルライターとして、私の最大の課題は、明快さと複雑さのスイートスポットを見つけることです。テキストが単純すぎると、幼稚に感じられることがあります。複雑すぎると、読みにくくなります。読みやすさは、物事を簡単にするだけではありません。それらを魅力的で知的に刺激的なものにすることです。
読みやすさの良いニュースは、それを測定できることです。完璧な指標はありませんが、Gunning Fog Indexは、ベースラインを取得するための優れたツールです。Gunning Fog Indexは、人が最初の読書でテキストを理解するために必要な正規教育の年数を推定する読みやすさテストです。たとえば、スコア12は、テキストが米国の高校3年生の読書レベルにあることを意味します。
インデックスは、次のアルゴリズムに基づいて計算されます。
- 100語以上のテキストのセクションを取ります。
- 平均文長を見つけます。
- 「複雑な」単語（3つ以上の音節を持つ単語）の数を数えます。
- 平均文長を複雑な単語のパーセンテージに加算します。
- 結果に0.4を掛けます。
あるいは、数学的に言えば、このアルゴリズムは次の方程式に変換されます。
\[ 0.4 \times \left[ \left( \frac{\text{単語数}}{\text{文の数}} \right) + 100 \left( \frac{\text{複雑な単語数}}{\text{単語数}} \right) \right] \]フォグインデックスの本来の意図は、テキストを理解するために必要な教育年数を推定することですが、教育年数で具体的に表現するのは役に立たないと思うので、自分のニーズに合わせてカスタマイズすることにしました。まず、特殊なケースを無視するように計算を簡略化しました。アルゴリズムの最も複雑な部分の1つは、単語が複雑かどうかを定義する方法です（意図的なしゃれ）。基本ケースは、3つ以上の音節がある場合に単語を複雑と見なすことですが、-ing、-ed、-esなどの特定の語尾を無視する特殊なケースを作成します。
これは、実装中に驚くほどの問題を引き起こしました。私は正確である必要はなく、シンプルさのために複雑さを見積もりすぎることに満足していました。この目的のために、私はすべての特殊なケースを無視し、音節を数えるための2つの基本的なルールを検討しました。1）単語の音節数は母音グループの数によって推定され、2）複雑な単語は3つ以上の音節を持つ単語です（例外なし）。
また、教育年数から読みやすさに対するより実用的なアプローチに焦点を移す分類システムも作成しました。
| スコア | 分類 | 説明 |
|---|---|---|
| >= 22 | 読めない | ほとんどの読者には理解できない可能性が高い。 |
| 18-21 | 読みにくい | 専門家でさえ、かなりの努力が必要。 |
| 13-17 | 専門家向け | 専門知識を持つ読者に最適。 |
| 9-12 | 一般向け | ほとんどの読者にとって明確でアクセスしやすい。 |
| < 9 | 単純すぎる | 子供っぽい、または過度に単純だと認識される可能性がある。 |
カスタマイズされた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サーバーのソースコード。
- Gemini CLIとGoでMCPサーバーを構築する方法: この旅のきっかけとなった前回の記事。
- Model Context Protocol (MCP): プロトコルの公式サイト。
- Gemini CLIの発表: カスタムスラッシュコマンドのサポートを発表したブログ投稿。
- Gunning Fog Index: 読みやすさの指標について詳しくはこちら。