コーディング用Grok：プロンプト、作業フロー、安全な習慣

Grokはスタックトレースの読解、関数の作成、テストの設計、複雑なコードの解説が可能です。入力すべき内容、指示の出し方、確認すべき重要事項をまとめました。

読了時間: 9 分更新日 2026年10月

Grokは、エラーメッセージの読み解き、小さな関数の作成、テストの設計、見慣れないファイルの解説、大まかなアイデアからの初期バージョンの構築など、日常的なプログラミング作業を支援する優れたコーディングパートナーです。当サイトのチャットでは、コードの実行、リポジトリの参照、最新ドキュメントの確認などは行えません。そのため、得られる回答の質は、どのようなコンテキストを入力するか、そして生成された内容をどれだけ慎重に確認するかに左右されます。本ガイドでは、その両方の実践的なポイントを解説します。

Grokが得意なこと・苦手なこと

Grokは、ひとつの会話内で完結する問題に対して最も高い効果を発揮します。得意なタスクは以下の通りです。

スタックトレースやコンパイラエラーを解析し、考えられる原因を提示する
単体で動作する関数、スクリプト、SQLクエリ、正規表現を作成する
コードブロックの処理内容を、必要に応じて1行ずつ解説する
思いつきにくいエッジケースを含めた単体テストを作成する
短い差分（diff）をレビューし、バグ、不適切な命名、バリデーション漏れを指摘する
言語間やライブラリのバージョン間でコードを移植・変換する

一方、未確認の複数ファイルにまたがる変更、ローカルシステムの正確な状態に依存する処理、学習データのカットオフ以降にリリースされたライブラリに関する質問などは苦手としています。また、Grok自身によるコードテストは行えません。生成されたコードスニペットは、ユーザー自身が実行して検証する必要があります。

新しいチームメンバーに伝えるようなコンテキストを共有する

的確なコード回答が得られない最大の理由は、コンテキストの不足です。質問する前に、以下の情報を整理してください。

言語とバージョン：「Python 3.12, pandas 2」や「Node 22, Express 5」のように明記します。バージョンの相違は誤答の大きな原因となります。
関連するコード：プロジェクト全体ではなく、エラーが発生している関数とその呼び出し先のみを提示します。
正確なエラー内容：要約せず、完全なエラーメッセージとスタックトレースをそのままコピー＆ペーストします。
期待する動作と実際の結果：本来どう動くべきか、実際にはどうなったか、すでに試した対策を記述します。
制約事項：新しい依存関係を追加しない、旧バージョンとの互換性を保つ、初心者にも読みやすいコードにする、などの条件を指定します。

改善前:
コードが動きません。直してください。

改善後:
Python 3.12です。この関数は顧客あたりの平均注文額を
返す必要がありますが、注文が1件のみの顧客に対してNaNが返されます。
期待する動作：その1件の注文額が返されること。
以下に関数とサンプルデータを示します。
まず原因を説明し、その後で修正後の関数を提示してください。
新しいライブラリは追加しないでください。
---
[関数]
[サンプルデータ5行]

改善後のプロンプトでは、言語、症状、期待する結果、順守すべき制約を明確に伝え、修正コードの前に原因の説明を求めているため、問題の本質を理解しやすくなります。

よくあるプログラミング作業向けプロンプト

エラーの解析

完全なスタックトレースと該当行のコードを貼り付けた上で、次のように指示します。「可能性の高い原因を上位3つ、確率が高い順に挙げてください。それぞれの確認方法もあわせて教えてください。」これにより、単一の推測だけでなく、段階的な切り分け手順が得られます。

関数の作成

入力、出力、エッジケースを平易な言葉で説明し、コードに加えて2〜3個の実行例と期待される出力を提示するよう依頼します。提示された例は、そのまま動作確認用テストとして活用できます。

テストの作成

以下の関数に対するpytestのテストを作成してください。
対象ケース：通常の入力、空の入力、単一要素、極端に大きな数値、無効な型。
ケースごとにわかりやすい名前を付け、1つのテストとして記述してください。
元の関数は変更しないでください。
---
[関数]

作成したコードのレビュー

レビューの観点を明確にして依頼します。例：「バグと未処理のエラーのみを対象にレビューしてください。コードスタイルは無視して構いません。」焦点を絞ることで、簡潔で実用的なアドバイスが得られます。ご自身のコードでレビュー用プロンプトを試してみてください。

見慣れないコードの解説

「JavaScriptの知識はあるものの、このライブラリは初めて使う開発者に向けて、このコードの動作を解説してください。その後、リスクとなりそうな箇所や非推奨の古い記法があれば指摘してください。」リスクの確認を求めることで、解説と同時に簡易レビューも兼ねることができます。

主導権を握るためのワークフロー

まず方針をすり合わせる：単一の関数を超える規模の場合は、コード生成を依頼する前に実装アプローチの概要を提示させます。方針を確定してからコードを作成させましょう。
小さな単位で進める：1メッセージにつき1つの関数、または1つの変更に留めます。出力が長すぎるとミスを見落としやすくなり、回答の文字数制限で途切れるリスクもあります。
必ず自分で実行する：実行結果や新たなエラーは、同じチャットに貼り付けてフィードバックします。「実行したところ、以下の結果になりました」という情報は、最も有効な追加プロンプトです。
コードを反映する前に全行を確認する：同僚に説明できない行がある場合は、Grokにその行の解説を求めるか、書き直しを指示してください。
こまめにコミットする：バージョン管理を活用していれば、期待通りに動かなかった提案もすぐに取り消すことができます。

コードアシスタントツールを使えば、タスクを選択してコードを貼り付けるだけで、構造化された回答をスムーズに得られます。開発者向けページでは日常業務での多様な活用法を紹介しており、入力してすぐに使えるコーディング用プロンプトも用意しています。

用途に応じたGrokモデルの選び方

Grok 4.20（デフォルト）：解説、短いスニペット、正規表現、ボイラープレートの作成などをスピーディに行うのに最適です。
Grok 4.3 Thinking：回答前に思考プロセスを挟むため、複雑なバグの追跡、アルゴリズム設計、多重分岐を含むロジックの構築に適しています。
Grok 4.7：当チャットで利用できる最新モデルであり、xAIがコーディングや自律的タスク向けフラッグシップと位置づけています。1日最大10メッセージまで利用可能です。必要なコンテキストを1つのメッセージにまとめ、最も難易度の高い課題を投入することをおすすめします。

思考プロセスの活用が効果的な場面については、推論モデルの解説ガイドをご覧ください。

注意すべきポイント

存在しない関数の捏造（ハルシネーション）：実在しそうな名称でありながら実際には存在しないメソッドやオプションを提示することがあります。見慣れない記述がある場合は、必ず公式ドキュメントで確認してください。
古いバージョンへの依存：知識にはカットオフ日が存在します。それ以降にライブラリの仕様変更や廃止が行われている可能性があるため、利用バージョンを明示し、不明な点は変更履歴を確認してください。
正常系のみのコード：初期出力では、空の入力、ファイル不在、タイムゾーン、ネットワークエラーなどの例外処理が省略されがちです。「このコードが動作しなくなる入力例はありますか？」と確認してください。
意図しないコード改変：1箇所を修正する過程で、別の部分を勝手にリファクタリングしてしまうことがあります。最小限の変更を指示するか、変更行のみの出力を求めてください。
セキュリティの脆弱性：文字列結合によるクエリ生成、入力検証の不足、ハードコードされたシークレットなどに注意が必要です。「このコードはSQLインジェクションに対して安全ですか？」と直接確認することをおすすめします。

まず失敗するテストを作成させる：修正コードを求める前に、そのバグを再現するテストケースの作成をGrokに依頼してください。ローカル環境でそのテストが失敗すれば問題を確認でき、修正後にパスすれば正しく解決された証明になります。

機密情報をチャットに入力しない

コードを貼り付ける前に、APIキー、パスワード、トークン、接続文字列、顧客データ、内部ホスト名などの機密情報を必ず削除してください。これらは「YOUR_API_KEY」などのプレースホルダーに置き換えます。所属組織に外部サービスへのソースコード共有に関するポリシーがある場合は、それに従ってください。判断に迷う場合は、機密情報を含まない形で同じ現象を再現する最小限のサンプルコードを作成することをおすすめします。その最小コードを作成する過程で、バグの原因が特定できることも少なくありません。当チャットでのメッセージの取り扱いについては、プライバシーとセキュリティガイドをご覧ください。