プロンプトエンジニアリング on KnightLiブログ

Prompt Optimizer：プロンプト最適化、テスト、MCP に対応したオープンソースツール

Fri, 01 May 2026 03:09:07 +0800

Prompt Optimizer は、プロンプトを改善するためのオープンソースツールです。目的は明確で、粗いプロンプトをより明確で安定し、LLM が実行しやすい形に整えることです。

単に「prompt をきれいに書き直す」ページではありません。プロンプト最適化、結果テスト、比較評価、複数モデル接続、画像生成プロンプト処理、MCP 連携まで備えています。システムプロンプト、ユーザープロンプト、AI ワークフローテンプレートをよく書く人にとっては、専用のプロンプト作業台に近いツールです。

解決する問題

AI を使っていると、よく次のような問題にぶつかります。

プロンプトは長くなるのに、出力品質があまり改善しない
同じタスクでも、モデルを替えると挙動が安定しない
システムプロンプトとユーザープロンプトが混ざり、デバッグしにくい
プロンプトを変更しても、前の版より良くなったか判断しにくい
変数テンプレートを再利用したいが、毎回の置換とテストが面倒
他の AI ツールからプロンプト最適化を呼びたいが、標準的な入口がない

Prompt Optimizer は、こうした問題を中心に設計されています。「prompt を書く」という作業を、最適化、テスト、評価、比較、反復に分けることで、感覚だけに頼らない調整をしやすくします。

主な機能

1. システムプロンプトとユーザープロンプトの最適化

プロンプトには複数の種類があります。

システムプロンプトは通常、役割、目的、境界、出力ルール、作業方法を定義します。ユーザープロンプトは、個別タスクの入力に近いものです。この 2 つが混ざると、モデルが重要点を捉えにくくなり、再利用もしづらくなります。

Prompt Optimizer は、システムプロンプトとユーザープロンプトの両方の最適化に対応しています。長期的に使うロール設定と、特定タスクの入力表現を分けて扱えます。

次のような場面で役立ちます。

AI コーディングアシスタントの作業ルールを書く
カスタマーサポート、レビュー、翻訳、分析ロールのプロンプトを書く
text-to-image 用プロンプトを最適化する
一時的な要件を再利用可能なテンプレートにする
モデルごとに異なるスタイルの prompt を用意する

2. 出力のテストと比較

プロンプトを最適化するだけでは不十分です。重要なのは、最適化後に本当に良くなったかどうかです。

このプロジェクトは、分析、単一結果の評価、複数結果の比較評価をサポートしています。元のプロンプトと最適化後のプロンプトを同じタスクで実行し、出力がより正確で安定し、目的に合っているかを比較できます。

これは、単に「見た目が専門的」な prompt より実用的です。表面上は整っていても、実際には冗長、硬直的、あるいはモデルを誤った方向へ導くプロンプトもあります。比較テストは、そうした問題を早めに見つける助けになります。

3. 複数モデル対応

README によると、このプロジェクトは OpenAI、Gemini、DeepSeek、Zhipu AI、SiliconFlow などのモデルサービスに対応し、OpenAI 互換のカスタム API も利用できます。

これは重要です。プロンプトの効果はモデルに強く依存します。同じ prompt でも、モデルが変わると結果が大きく変わることがあります。複数モデルのテストにより、次の判断がしやすくなります。

プロンプト自体が弱いのか
特定のモデルがそのタスクに向いていないのか
モデルごとに別バージョンを用意すべきか
小さいモデルでも、より明確なプロンプトで実用に近づけるか

ローカルで Ollama を使っている場合や、社内に OpenAI 互換 API のモデルサービスがある場合も、カスタム API として接続できます。

4. 高度なテストモード

プロジェクトは、コンテキスト変数管理、複数ターン会話テスト、Function Calling に対応しています。

変数管理はテンプレート化されたタスクに向いています。たとえば、中古取引の返信、商品説明、メール返信、コードレビュー、ドキュメント生成用のプロンプトがある場合、商品、価格、口調、対象ユーザーなどの変数を差し替えるだけで、入力ごとの挙動を素早く確認できます。

複数ターン会話テストは、長い対話での挙動を確認するのに向いています。単発の質問では良く見える prompt でも、追質問が続くと制約を忘れたり、役割から外れたり、説明を繰り返したりします。複数ターンテストは、実利用に近い検証になります。

Function Calling 対応は、よりエンジニアリング寄りの AI アプリに適しています。ツール呼び出し、パラメータ生成、構造化出力におけるモデルの挙動を確認できます。

5. 画像生成プロンプト

Prompt Optimizer は、text-to-image と image-to-image に関連する機能にも対応しています。README では Gemini、Seedream などの画像モデルとの連携が紹介されています。

画像生成プロンプトの最適化は、テキストタスクとは重点が異なります。主体、構図、空間関係、スタイル、質感、光、感情、制約条件などが重要になります。曖昧な一文を制御しやすい視覚記述に分解することは、単にプロンプトを長くするより価値があります。

商品画像、カバー、イラスト、キービジュアル、スタイル参照画像をよく生成するなら、この種の最適化は実用的です。

使い方

プロジェクトには複数の入口があります。

オンライン版
Vercel でのセルフホスト
デスクトップアプリ
Chrome 拡張
Docker デプロイ
Docker Compose デプロイ
MCP Server

オンライン版は素早い試用に向いています。プロジェクト説明では、純粋なフロントエンドアプリであり、データはブラウザローカルに保存され、AI プロバイダーと直接やり取りすると説明されています。

デスクトップアプリは、さまざまなモデル API に直接接続したい場合に向いています。ブラウザ環境では CORS の制限に遭遇しやすいですが、デスクトップアプリならそれを回避しやすく、ローカル Ollama や厳しい CORS ポリシーを持つ商用 API にも向いています。

Docker デプロイは、自分のサーバーや社内環境で使う場合に向いています。README の基本コマンドは次のとおりです。

`1`	`docker run -d -p 8081:80 --restart unless-stopped --name prompt-optimizer linshen/prompt-optimizer`

API キーとアクセスパスワードを設定する場合は、環境変数を渡します。

docker run -d -p 8081:80 \
  -e VITE_OPENAI_API_KEY=your_key \
  -e ACCESS_USERNAME=your_username \
  -e ACCESS_PASSWORD=your_password \
  --restart unless-stopped \
  --name prompt-optimizer \
  linshen/prompt-optimizer

中国国内で Docker Hub へのアクセスが遅い場合は、README の説明に従って Alibaba Cloud のイメージ名に置き換えることもできます。

MCP でできること

Prompt Optimizer は Model Context Protocol、つまり MCP に対応しています。

Docker で実行する場合、MCP サービスは Web アプリと一緒に起動でき、/mcp パスからアクセスできます。これにより、単なる Web ツールではなく、Claude Desktop などの MCP 対応アプリから呼び出せるツールになります。

README に記載されている MCP ツールは次のとおりです。

optimize-user-prompt：ユーザープロンプトを最適化
optimize-system-prompt：システムプロンプトを最適化
iterate-prompt：既存プロンプトを目的に沿って反復改善

こうしたインターフェースは AI ワークフローに向いています。たとえば複雑なタスク用プロンプトを書くとき、MCP 対応クライアントから直接プロンプト最適化を呼び出せるため、毎回 Web ページを開いてコピーする必要がありません。

通常のチャットツールとの違い

通常のチャットツールでも prompt の書き直しはできますが、次のような点が不足しがちです。

複数バージョンの保存と比較がしづらい
複数モデルを同時にテストしづらい
変数をテンプレート化しづらい
複数ターン会話の検証がしづらい
MCP 連携やセルフホストがしづらい

Prompt Optimizer の価値は、プロンプト最適化を再現可能なプロセスにすることです。「より完成度が高く見える」文章を出すだけでなく、実際の出力を見ながら継続的に調整できます。

向いている人

次のような人は、このプロジェクトに注目するとよいでしょう。

システムプロンプトをよく書く
AI アプリ用のロールや出力形式を設計する
異なるモデルの出力を比較したい
prompt を再利用可能なテンプレートにしたい
複数ターン対話やツール呼び出しをテストしたい
プロンプト最適化を MCP ワークフローに接続したい
ローカルまたは社内環境にプロンプトツールをデプロイしたい

たまに AI に簡単な質問をするだけなら、普通のチャット画面で十分です。このツールは、プロンプトを保守可能な資産として扱う人に向いています。

利用時の注意

第一に、最適化結果を絶対に正しいものとして扱わないことです。

プロンプト最適化ツールは表現品質を高められますが、モデルが誤解しないことを保証するものではありません。重要なタスクでは、テストケース、人手の確認、バージョン比較が必要です。

第二に、長さだけを追わないことです。

良い prompt は必ずしも長いとは限りません。目的、境界、入出力形式、判断基準をより明確に表すべきです。意味の薄いルールを積み重ねると、かえってモデルが要点を見失います。

第三に、モデルに合わせて prompt を調整することです。

モデルによって、役割設定、形式制約、推論手順、例への反応は異なります。大きなモデルでうまく動くプロンプトが、小さなモデルにも合うとは限りません。複数モデルテストは、このツールを使う理由の一つです。

第四に、デプロイ時はキーとアクセス制御を考慮することです。

公開環境にデプロイする場合は、アクセスパスワードを設定し、API key を慎重に扱うべきです。プロジェクトは環境変数によるアクセス制御に対応しています。機密設定を公開リポジトリへ直接書かないようにしてください。

参考

linshenkx/prompt-optimizer

最後に

Prompt Optimizer は、プロンプトを「その場で手書きした一段落」から「テスト、比較、反復できる作業資産」へ整理するためのツールです。

複数のモデル、複数の場面、複数のバージョンにまたがって prompt を保守し始めると、通常のチャット画面よりもこうしたツールの方が扱いやすくなります。

Karpathy の 65 行の CLAUDE.md：AI コーディングで三つの典型的なミスを減らす

Sun, 19 Apr 2026 18:27:23 +0800

最近、AI コーディングに関する GitHub プロジェクトが注目を集めている。中心にあるのは複雑なコードではなく、およそ 65 行の CLAUDE.md ファイルだ。このプロジェクトが多くの star を集めた理由は、技術実装の複雑さではない。AI にコードを書かせるとき、多くの人が繰り返し遭遇する問題をうまく捉えているからだ。

背景には、Andrej Karpathy による AI コーディングへの観察がある。Karpathy は AI 分野で大きな影響力を持つ教育者でありエンジニアだ。スタンフォード大学の博士で、OpenAI の初期にも関わり、Tesla では Autopilot の視覚システムを担当した。その後も大規模モデル、教育、AI ツールについて発信を続けているため、彼がプログラミング手法の変化について語ると、多くの開発者が注目する。

彼は、Claude Code を数週間使ったあと、自分のプログラミングスタイルが大きく変わったと述べている。以前はおよそ 80% を手書きし、20% を AI に補助させていた。今は 80% を AI に書かせ、自分は 20% を修正する感覚に近いという。自然言語で LLM に何を書くべきか伝えるので、「英語でプログラミングしている」ようなものだと表現している。

一方で、彼は AI コーディングにありがちな問題も指摘している。

01 誤った仮定

一つ目の問題は、モデルがユーザーの代わりに勝手な仮定を置き、その仮定に沿って書き進めてしまうことだ。モデルは必ずしも自分の混乱を管理しないし、要件が曖昧なときに立ち止まって質問するとも限らない。

たとえばユーザーが「ユーザーのエクスポート機能を追加して」とだけ言った場合、モデルは全ユーザーを出力する、JSON 形式にする、ローカルファイルに書き出す、権限や項目は確認不要だ、と勝手に決めるかもしれない。コードが完成してから、ユーザーはモデルの理解が実際のシナリオとずれていたことに気づく。

よりよい進め方は、不確かな点を先に列挙することだ。全ユーザーを出力するのか、フィルタ後の結果なのか。ブラウザでダウンロードするのか、バックグラウンドジョブなのか。必要な項目は何か。データ量はどれくらいか。権限制御はあるのか。こうした点を確認しないまま速く書いても、ずれが大きくなるだけだ。

02 過度な複雑化

二つ目の問題は、モデルが簡単な問題を複雑にしがちなことだ。一つの関数で済む問題に対して、抽象クラス、ストラテジーパターン、ファクトリーパターン、設定レイヤー、将来使うかもしれない拡張ポイントを山ほど追加することがある。

こうしたコードは一見エンジニアリングされているように見えるが、実際には保守コストを増やす。AI は大量の構造を素早く生成するのが得意だが、その構造が本当に必要かを常に判断できるわけではない。その結果、100 行で済むタスクが 1,000 行に膨らむ。

判断基準はシンプルだ。経験あるエンジニアがその変更を見て、過剰設計だと感じるかどうか。答えが yes なら、余分な層を削り、今の問題を解くために必要な最小限のコードに戻すべきだ。

03 付随的な被害

三つ目の問題は、モデルが十分に理解していないコードを変更したり削除したりすることだ。小さな bug を直している途中で、ついでにコメントを変えたり、フォーマットを整えたり、未使用に見える import を消したり、現在のタスクと無関係なロジックにまで手を入れることがある。

こうした「ついでの改善」は危険だ。変更範囲を広げ、レビューを難しくするからだ。ユーザーは空の email でバリデータが落ちる問題だけを直したいのに、モデルが email 検証を強化し、ユーザー名検証を追加し、ドキュメント文字列まで書き換えると、どの行が挙動を変えたのか分かりにくくなる。

より安全な原則は、必要なコードだけを変更し、自分の変更によって生まれた問題だけを片付けることだ。もともと存在していた dead code、フォーマットの問題、歴史的な負債は、明示的に依頼されていない限り触らない。必要なら一言指摘するだけでよい。

04 不満を CLAUDE.md に変える

Karpathy の見解が広く共有されたあと、開発者の Forrest Cheung は賢いことをした。これらの不満を、実行可能な行動指針として整理し、CLAUDE.md ファイルに書き込んだのだ。

このプロジェクトには複雑なコードはない。重要なのは、AI コーディングで問題が起きやすい部分を、明確な作業ルールに変えたことだ。大きく四つの原則にまとめられる。

一つ目は、書く前に考えること。黙って仮定しない。混乱を隠さない。要件に複数の解釈があるなら列挙する。より簡単な案があるなら伝える。確認が必要なら質問し、反論すべきときは反論する。

二つ目は、シンプルさを優先すること。求められていない機能を追加しない。一度しか使わないコードを抽象化しない。余計な設定を増やさない。ほぼ起きないケースのために大量の防御コードを書かない。50 行で済むなら 200 行にしない。

三つ目は、正確に変更すること。すべての変更行は、ユーザーの依頼に直接結びついているべきだ。近くのコードをついでに改善しない。壊れていないものをリファクタリングしない。できるだけ既存プロジェクトのスタイルに合わせる。

四つ目は、目標駆動で進めること。モデルに曖昧な指示だけを渡すのではなく、検証可能な成功基準を与える。たとえば「bug を直す」は「bug を再現するテストを書き、それを通す」にできる。「バリデーションを追加する」は「不正入力のテストを書き、それを通す」にできる。成功基準が明確なほど、モデルは完了に向けて自分でループしやすくなる。

05 なぜ広まったのか

このプロジェクトが広まったのは、内容が難解だからではない。実際の開発に近いからだ。

AI にコードを書かせたことがある人の多くは、似た場面を経験している。モデルが自信満々に要件を誤解する。コードがどんどん複雑になる。触るべきでない場所を変更する。CLAUDE.md の価値は、こうした経験をプロジェクトに置ける協作ルールに変えたことにある。

導入の敷居も低い。複雑な連携は不要で、一つのファイルから始められる。Karpathy 本人の影響力に加え、プロジェクト内に実践的な比較例があるため、Claude Code ユーザーや AI コーディングコミュニティの間で自然に広まった。

さらに重要なのは、この種のルールが Claude Code だけに限られないことだ。どの AI コーディングツールを使っても、本質的な問題は似ている。モデルは、いつ質問すべきか、いつ単純化すべきか、いつ手を止めるべきか、どうやってタスク完了を判断するかを知る必要がある。

06 普通の開発者への示唆

普通の開発者にとっての示唆はシンプルだ。AI コーディングは、一文の要件をモデルに投げて奇跡を待つものではない。本当に有効なのは、モデルに境界を与えることだ。

要件が不明確なときは、まず仮定を表に出させる。実装が複雑になり始めたら、最小の実用解に戻らせる。コードを変更するときは、タスクの目的だけに集中させる。完了時には、テスト、コマンド、明確なチェックポイントで結果を検証する。

AI がコードを書く能力はすでに高い。それでも、よい協作上の制約は必要だ。短い CLAUDE.md がこれほど注目されたことは、開発者が求めているのはより賢いモデルだけではなく、より信頼できる作業方法でもあることを示している。

簡単にまとめると：

書く前に考え、誤った仮定を減らす。
シンプルさを優先し、過度な設計を避ける。
正確に変更し、変更範囲を制御する。
検証可能な成功基準で、目標に向かって進める。

この四つは複雑ではないが、実用的だ。AI コーディングが本当に効率を上げる前提は、モデルにより多く書かせることではない。より正確に、より少なく、より制御された形で書かせることだ。