Kimi K3.1 Pro プロンプト大全：5 つのシーンでそのままコピーして結果を出せる

Kimi K3.1 Pro は HiAPI で公開中。新規ユーザー登録で 200 クレジットを進呈。以下は実際に使える 5 つのプロンプトで、トラブルシューティング、コードレビュー、方案比較、長文ドキュメント分析、データ処理をカバーしています。どのプロンプトもそのままコピーでき、リンクをクリックすれば自動で入力されます。

1. システムトラブルシューティング：エラーログから根本原因を特定する

エラーログをモデルに渡し、呼び出し経路に沿って層ごとに調査させ、根本原因と修復手順を出力させます。「ネットワーク接続を確認してください」といった曖昧な回答ではありません。

出力サンプルの参考：モデルは調査経路（例：Nginx リバースプロキシ設定 → バックエンドサービスのヘルス状態 → データベース接続プール）を列挙し、各層について確認コマンド、期待される結果、異常時の挙動を示し、最後に根本原因（例：「PostgreSQL の接続プール枯渇により新規リクエストがキューでタイムアウト」）を特定し、2 ステップの修復案を提示します。

あなたはバックエンドのトラブルシューティングエンジニアです。以下は本番環境のエラーログです。次の手順で調査してください：

1. ログ内の重要なタイムスタンプとエラーコードを 1 行ずつ解読する
2. 呼び出し経路（入口 → ミドルウェア → サービス → データベース）に沿って層ごとに考えられる原因を分析する
3. 最も可能性の高い根本原因を挙げる（3 件以内）
4. 各根本原因について検証コマンドと修復手順を示す

出力形式：
## ログの解読
## 層ごとの調査
## 根本原因の分析
## 修復手順

ログ：
[エラーログを貼り付け]

このプロンプトでトラブルシューティングする →

kimi-k3.1-pro、reasoning_effort: high。参考：約 $0.03（入力約 3000 token + 出力約 2000 token）。

ポイント：プロンプト内で出力構造と呼び出し経路を定義しているため、モデルはステップを飛ばしたり、「再起動してみてください」のような無意味な提案をしたりしません。トラブルシューティング系の問題では reasoning_effort を high または max にするとより有用です——low では中間層を飛ばして結論を推測してしまうことがあります。

2. コードレビュー：構造化 JSON 出力

モデルにコードをレビューさせ JSON で出力させれば、そのままデータベースに登録して CI チェックに使えます。K3.1 Pro の json_schema モードは、出力のフィールド、型、列挙値が定義に厳密に一致することを保証します。

出力サンプルの参考：モデルは JSON オブジェクトを返します。内容は issues 配列（各項目に file、line、severity、category、description、suggestion を含む）、summary オブジェクト（各重大度レベルの件数を含む）、そして overall_score（0-100）です。重大度は critical / major / minor / style の 4 段階で厳密に分類されます。

以下のコードをレビューしてください。JSON Schema に厳密に従ってレビュー結果を出力し、JSON 以外には一切テキストを出力しないでください。

レビュー観点：
- 論理エラーと境界条件
- パフォーマンス問題（N+1 クエリ、不要なループ）
- セキュリティリスク（SQL インジェクション、XSS、未検証の入力）
- コードスタイルと可読性

出力 JSON Schema：
{
  "issues": [
    {
      "file": "string",
      "line": "number",
      "severity": "critical | major | minor | style",
      "category": "logic | performance | security | style",
      "description": "string",
      "suggestion": "string"
    }
  ],
  "summary": {
    "critical": "number",
    "major": "number",
    "minor": "number",
    "style": "number"
  },
  "overall_score": "number (0-100)"
}

コード：
[コードを貼り付け]

このプロンプトでコードをレビューする →

kimi-k3.1-pro、response_format: json_schema。参考：約 $0.04（入力約 4000 token + 出力約 2500 token）。

ポイント：出力形式を固定するには response_format: {"type": "json_schema", "json_schema": {...}} を必ず渡す必要があります。プロンプトにも Schema を一度書いておくのは二重の保険です——json_schema が効かなかったとしても、モデルはその形式で出力します。severity は自然言語の説明ではなく列挙値を使うことで、下流で直接分岐判定できます。

3. 技術方案の比較：多次元スコア表

2 つの技術方案で決めきれないとき、モデルに複数の次元で採点させ、合計点を算出させれば、同僚の直感に頼るより公平です。

出力サンプルの参考：モデルは比較表を生成します。次元は性能、保守性、エコシステムの成熟度、学習コスト、チームとの適合度など 5〜6 項目で、各項目に 1〜10 点と一言の理由を付け、最後に重み付きで合計点を算出し、選択の提案を示します。

2 つの技術方案のどちらかを選ぶ必要があります：方案 A と方案 B。以下の 6 つの次元で 1 つずつ比較し、各次元を採点（1-10）して一言の理由を書き、最後に重み付きで合計点を算出し、推薦を示してください。

比較次元と重み：
- 性能（重み 25%）
- 保守性（重み 20%）
- エコシステムの成熟度（重み 20%）
- 学習コスト（重み 15%）
- チームの既存技術スタックとの適合度（重み 15%）
- コミュニティの活発度（重み 5%）

出力形式：
| 次元 | 方案 A の得点 | 方案 B の得点 | 理由 |
|---|---|---|---|
| 性能 | | | |
| ... | | | |
| **重み付き合計点** | | | |

最後の段落：推薦理由（3 文以内）

方案 A：[方案 A を説明。例：技術スタック、アーキテクチャ、主要な依存関係]
方案 B：[方案 B を説明。例：技術スタック、アーキテクチャ、主要な依存関係]
背景：[任意：チーム規模、既存技術スタック、業務シーン]

このプロンプトで方案を比較する →

kimi-k3.1-pro、reasoning_effort: high。参考：約 $0.04（入力約 3000 token + 出力約 3000 token）。

ポイント：重みは実際の状況に合わせて調整してください。チームにすでに傾向があるなら、重みをそのままプロンプトに書き込めば、モデルは採点時にそれを反映します。方案名だけを与えないでください——各方案の主要な技術選定、依存関係、チームの状況をはっきり書くことで、モデルは根拠のある点数を出せます。

4. 長文ドキュメント分析：マニュアル全体から重要情報を抽出する

数十ページの技術ドキュメント、会議議事録、ユーザーフィードバックを放り込み、本当に気になるいくつかの点をモデルに抽出させます。K3.1 Pro の 1M token コンテキストはマニュアル 1 冊を丸ごと飲み込むのに十分です。

出力サンプルの参考：モデルはまずドキュメントの主題と構成を要約し、次に各重要問題に 1 つずつ回答し、最後に見落としやすい境界ケースと矛盾点を列挙します。

以下は完全な技術ドキュメントです。次の構造で重要情報を抽出してください：

1. ドキュメントの主題と構成の概要（1 段落）
2. 次の具体的な質問に回答する：
   - [質問 1]
   - [質問 2]
   - [質問 3]
3. ドキュメントに記載されているすべての制約条件と前提仮定（1 条ずつ列挙）
4. 見落としやすい境界ケース（少なくとも 3 条）
5. ドキュメント内に矛盾や不明確な箇所（あれば）

ドキュメント：
[ドキュメント全文を貼り付け]

このプロンプトでドキュメントを分析する →

kimi-k3.1-pro、reasoning_effort: max、max_tokens: 8000。参考：約 $0.07（入力約 15000 token + 出力約 3000 token）。長文ドキュメントの入力 token は実際のドキュメント長で計算され、ここでは約 1 万漢字という保守的な見積もりに基づいています。

ポイント：質問 2 と 3 は、ドキュメントから本当に知りたい事柄に置き換えてください。テンプレートの [質問 1] を残さないでください。ドキュメントが非常に長い場合は reasoning_effort を max にしてください。low は長いコンテキストのシナリオでは情報を落としやすいです。同じ長文ドキュメントを繰り返し分析する場合、2 回目以降のキャッシュ読み取りは $0.2156/M token だけで済みます（入力価格の 1/10）。

5. データ分析：生データからインサイトレポートを生成する

CSV や JSON のデータを渡し、自動で統計、傾向の発見、異常の特定を行わせ、週報にそのまま貼れるレポートを出力させます。

出力サンプルの参考：モデルはまずデータ概観（行数、フィールド、期間）を行い、次に主要指標の統計、傾向の記述、異常データ点の注記を出力し、最後に実行可能な提案を 2〜3 条示します。

あなたはデータアナリストです。以下は生データです。次の分析を完了し、レポートを出力してください：

1. データ概観：行数、フィールド一覧、期間、データ完全性（欠損率）
2. 主要指標の統計：フィールドの型に応じて適切な統計量を自動選択する
   - 数値フィールド：平均値、中央値、最大値、最小値、標準偏差
   - カテゴリフィールド：Top 5 カテゴリとその割合
3. 傾向分析：日時フィールドがあれば、主要指標を週/月単位で集計し、傾向を記述する
4. 異常検出：平均値から 2 標準偏差を超えて外れるデータ点を注記する
5. 結論と提案：実行可能な提案を 2〜3 条

出力形式：Markdown レポート、セクション見出し付き、主要な数値は太字。

データ：
[CSV または JSON データを貼り付け]

このプロンプトでデータを分析する →

kimi-k3.1-pro、reasoning_effort: high。参考：約 $0.03（入力約 2000 token + 出力約 2000 token）。データ量が多い場合は入力 token がそれに応じて増えます。

ポイント：データに機密情報（実在のユーザー ID、電話番号、鍵）を含めないでください。データの行数が多い場合、先頭 200 行あればモデルが傾向や異常を発見するのに十分です——K3.1 Pro は全量データがなくても正確な統計結論を出せます。

プロンプトの共通の書き方

K3.1 Pro は推論モデルなので、プロンプトに「あなたはプロの XX です」といった万能な前置きを書く必要はありません。3 つのポイント：

1. 考え方ではなく構造を与える：出力形式と必ずカバーすべき次元を定義し、どう埋めるかはモデル自身に推論させる方が、手取り足取り手順を教えるより効果的です。
2. 具体的な質問をする：「このログを分析して」より、「この 500 行のログで最初に現れた異常、その上流の呼び出し元、そして修復にどの設定を変える必要があるかを特定して」の方が良いです。
3. reasoning_effort はシーンに応じて選ぶ：トラブルシューティングや長文ドキュメントには high または max、簡単な Q&A や形式変換には low を使うと、コストが数倍変わります。

Kimi K3.1 Pro のモデルページを開く。シーンを 1 つ選び、プロンプトをコピーして、生成を始めましょう。

Kimi K3.1 Pro シリーズ記事

• モデルページ
• API の使い方は？5 分で最初の呼び出しを動かす
• 価格比較
• Kimi K3.1 Pro vs Claude Opus 5.5