Kimi K3.1 Proの使い方

Kimi K3.1 Proを使うには、アクセス手段を選び、モデルとの新しい会話を開始し、必要な素材とともに具体的なタスクを指示します。Kimiの製品とAPIからモデルにアクセスできます。Kimi K3.1 ProはiWeaverでも利用可能で、モデルの無料トライアルが提供されています。

最初に行うと効果的なタスクは、確認できる結果が得られるものです。たとえば2つのドキュメントの比較、難解な一節の説明、再現可能なコーディング課題の修正などです。このガイドでは、それらのタスクを手順に沿って紹介し、毎回ゼロから始めずに結果をブラッシュアップする方法を示します。

Kimi K3.1 Proを使う場所を選ぶ

開始する前にリリースの詳細を確認するには、Kimi K3.1 Proで新しくなったこと.をご覧ください。

Kimiのリリース発表には、Webサイト、アプリ、Kimi Work、Kimi Code、APIを通じたアクセスが記載されています。完了したいタスクに合うルートを選びましょう。

これらのルートには、それぞれ異なるアカウント要件、利用可能範囲、管理設定があります。あるサービス経由でのモデルアクセスが、別のサービスの条件を自動的に確立するわけではありません。

初めての試行では、ゴールが統合（インテグレーション）でない限り、APIの設定は避けましょう。チャットやドキュメントのワークフローで、完了して確認できるタスクから始めてください。

タスクを定義し、モデルを選び、ソースを用意し、結果を確認してから改善します。

ステップ1：素材を追加する前に「結果」を定義する

どんなものを受け取りたいのかを書き出しましょう。「これらのファイルを分析して」とだけでは、範囲が広すぎます。「提案されたローンチ計画を、インタビューのメモと比較し、裏付けのない前提を特定する」と指示すると、モデルの仕事がより明確になります。

役立つタスク説明には、4つの要素が含まれます。

• 回答してほしい問い。
• 回答が使うべきソース。
• 最終出力の形式。
• 特に注意が必要な詳細。

たとえば：

ローンチ計画を顧客インタビューのメモと比較してください。提案する機能の表、裏付けとなるインタビューの証拠、未解決の質問を作成します。添付された資料のみを使用してください。提案と、ドキュメントに記載された事実は分けてください。

最初の課題は狭めに設定しましょう。モデルがソースを理解しているか確認できた後で、拡張すればよいのです。

ステップ2：新しいセッションを開始してモデルを選ぶ

2つのバリアントのどちらを選ぶか迷っている場合は、K3.1 Pro vs. Highspeed.をご覧ください。

利用しているサービスで利用可能なモデルコントロールから、Kimi K3.1 Proを選びます。Kimi Code CLIでの公式なモデルセレクターは/modelです。新しいモデルに切り替える際は、新しいセッションを推奨しています（ドキュメントに記載のとおりです）。

モデルが見当たらない場合は、アカウントの提供内容と現在のモデル一覧を確認してください。公式のKimiクライアントでは、再起動や再サインインによって利用可能性が更新される場合があります（ドキュメントで説明されているとおり）。サードパーティのサービスには、それぞれ独自のロールアウト手順があることがあります。

別のタスク由来の前提を含む長い会話をそのまま続けるのは避けましょう。新しいセッションなら、適切な文脈を用意し、回答を判断しやすくなります。

ステップ3：ソースを使いやすい順序で渡す

ファイル名を分かりやすくし、その関係を説明してください。「現行の方針」と「旧い方針」は、そのようにラベル付けしましょう。インタビューのメモは、帰属（attribution）が重要な場合は、話者名や識別子を保持してください。

長い回答を書く前に、モデルにソースセットを確認させます。

利用できるドキュメントを列挙し、それぞれの見かけの日時と、各ドキュメントがどんな問いの答えに役立つかを示してください。読めないファイルや、比較を妨げる不足情報があればフラグを立ててください。

このチェックポイントは、読めない添付ファイルやバージョンの不一致を早期に発見するのにも役立ちます。また、モデルがそこを土台に議論を組み立てる前に、スコープを修正できるチャンスにもなります。

Kimiは大きなコンテキストウィンドウをうたっていますが、利用可能な範囲はアクセス手段とプランによって変わります。「1回のアップロードでプロジェクト内のすべてのファイルを含められる」とは決めつけないでください。サービス側の実際の上限を確認しましょう。

ステップ4：洗練されたレポートの前に、根拠を求める

ドキュメント作業では、まずエビデンステーブル（根拠一覧）から始めましょう。iWeaverでは、K3.1 Proに焦点を絞った比較を依頼する前に、AI Document Summarizerを使って素材に方向づけできます。

このプロンプトを試してみてください。

研究の問いに答えるために必要な根拠を抽出してください。各ポイントについて、確認できるソース名、参照できる一節または場所、そしてその意味を変える可能性のある条件（資格づけ）を示してください。対立（conflicts）は別々に列挙してください。まだ最終レポートは書かないでください。

表を確認します。各一節は主張を支えていますか？ある顧客に関する記述が、すべての顧客に関する記述になっていませんか？予測が、観測された結果として扱われていませんか？

根拠が固まったら、成果物を依頼します。

レビューした根拠を、600語のブリーフィングに変換してください。最初に、それが支える意思決定を示し、最も強い根拠を説明したうえで、未解決の質問で締めてください。ソース素材に含まれる不確実性は維持してください。

この2段階のプロセスにより、文章が磨かれる前に推論を修正できます。

ステップ5：狙いを定めたフォローアップを使う

回答が的外れだったときは、問題を正確に特定しましょう。「もう一度やって」では指示が曖昧です。

回答が広すぎる場合は、1つの意思決定に絞って扱うよう求めます。証拠と意見が混ざっているなら、別セクションに分けてください。裏付けのない結論なら、「その結論を確立するソースはどれで、どの弱い言い回しなら正当化できるか」を尋ねます。

たとえば：

3段落目の提案を修正してください。インタビューメモは関心を示していますが、支払い意向は示していません。その違いを明確に保ち、それを解決できる証拠は何かを説明してください。

PDFの視覚的な概要を把握するなら、PDF to Mind Mapのワークフローが役立ちます。枝ラベルを詳細な主張として頼る前に、もう一度ソースを確認してください。

コーディングにK3.1 Proを使う

同じ作業のために別のモデルを評価している場合は、Kimi K3.1 Pro vs. Claude Opus 5.5.のタスク基準を使ってください。

コーディングタスクには、再現可能なスタート地点と、観測可能な完了条件を与えましょう。エラー、期待される挙動、関連するプロジェクトの制約を含めます。

失敗しているdate-parserテストを再現してください。原因を特定し、最小限で妥当な変更を行い、関連するチェックを実行してください。修正で変更される挙動と、検証できなかったケースについて説明してください。

変更されたファイルとテスト結果を確認します。実装がそれを裏付けている場合に限り、自信のある説明は有用です。

統合（インテグレーション）の場合は、アクセスチャネルに対応するドキュメントから、モデルの識別子とエンドポイントをそのままコピーしてください。Kimi Codeおよび一般的なAPIは、チャネル固有の命名規則を使用します。チャットメニューの表示名をAPIリクエストにそのまま置き換えないでください。

最初の実行でのトラブルシューティング

1つの完了したタスクで、次に何をするかを決めましょう。K3.1 Proが整ったエビデンステーブルを出すのにレポートが焦点から外れている場合は、文章の指示を改善します。ソースの詳細が抜けているなら、まずソースの整理とチェックポイントを見直してください。小さなタスクで信頼できる結果が得られた後に、作業量を拡張しましょう。