開発者向けGrok

Grok は、対話しながら壁打ちができる心強い「ラバーダック」です。grok.online なら完全無料で登録も不要です。手早い質問には高速な Grok 4.20、回答前に思考を巡らせる Grok 4.3 Thinking はバグ調査に最適です。そして最新モデルの Grok 4.7 は、1日30通のうち10通を使って最も難解な課題に挑めます。3モデルすべてがスクリーンショットの読み取りに対応しています。ここではチャットですぐに使える調整可能なプロンプトとともに、7つの活用法をご紹介します。

問題の発見と修正

デバッグ時間の多くは「何が起きているか」の把握に費やされます。以下のプロンプトを使えば、そのプロセスを大幅に短縮できます。

スタックトレースの解読

エラーは要約せず全文を貼り付け、該当する行も併せて提示します。修正案の前に、まず原因をわかりやすい言葉で説明してもらいましょう。

[フレームワーク] を使用した [言語とバージョン] のコードです。以下が完全なエラー内容とスタックトレースです：[エラーを貼り付け]。該当箇所はこちらです：[コードを貼り付け]。何がなぜ起きたのかをわかりやすい言葉で説明し、最も可能性の高い原因を最初に挙げた上で、最小限の修正案を提示してください。

チャットで開く。Code Assistant でも同じ作業を1つの画面で行えます。

他人が書いたコードの構造把握

コメントのないファイルを突然引き継ぐのは、エンジニアの通過儀礼のようなものです。変更を加える前に、注意すべき箇所を含めたコード全体の解説を求めましょう。

引き継いだばかりの [言語] のファイルで、[機能] を変更する必要があります。このファイルが担う役割、実行順に沿った主要な関数、注意すべきグローバル変数や副作用、そして最も安全に変更を加えられる場所について、簡潔に解説してください：[コードを貼り付け]

解説を見る。気になる関数があればさらに質問を重ねましょう。

思考モデルによるロジックバグの追跡

クラッシュはしないものの出力が正しくない場合、入念なステップ追跡が必要です。Grok 4.3 Thinking は回答前にコードを順を追ってトレースするため、オフバイワンエラーや条件分岐の不具合の特定に適しています。

この [言語] の関数は [期待される動作] を行うはずですが、[入力値] を渡すと [期待される出力] ではなく [実際の出力] が返ってきます。その入力値での処理フローをステップバイステップでトレースし、各ステップでの主要な変数の値を示した上で、問題が発生している正確な行を指摘してください：[関数を貼り付け]

Grok 4.3 Thinking でトレースする。

スクリーンショットからレイアウト崩れを修正

現状のページのスクリーンショットを添付し、関連する HTML と CSS を貼り付けて、本来どう表示されるべきかを指示します。

ページのスクリーンショットを添付しました。[画面幅が狭いとサイドバーがコンテンツに重なるなど、問題を説明] という問題が発生しています。該当箇所の HTML と CSS は以下の通りです：[コードを貼り付け]。原因を説明し、変更を最小限に抑えた修正後の CSS を提示してください。

このプロンプトを開く（スクリーンショットを添付してください）。

リスクの高いリファクタリングの計画

肥大化したモジュールの整理こそ、最新モデルの貴重な送信枠を使う価値があります。いきなり書き直させるのではなく、まずは計画を立ててもらいましょう。

以下は変更が難しくなってしまった [言語] のモジュールです：[コードを貼り付け]。まだ書き直さないでください。このモジュールの責務、隠れた依存関係、各ステップ完了後もコードが正常に動作し続ける小さなステップでのリファクタリング計画を提示してください。また、ステップ1の前にどのテストを追加すべきかも教えてください。

Grok 4.7 で計画を立てる。計画ができたら、各ステップを Grok 4.20 に送って実装を進めましょう。

周辺コード・タスクの作成

テスト、クエリ、レビュー、ドキュメント作成は、納期が迫ると真っ先に後回しにされがちな部分です。

見落としがちなエッジケースのテスト作成

テストコードの前に、まずケースの一覧を出力させます。価値があるのはそのケースの洗い出しです。

以下は [言語] の関数です：[関数を貼り付け]。まず、空の入力、境界値、不正な型など、テストすべきエッジケースの一覧と、その理由をそれぞれ1行で挙げてください。その後、[テストフレームワーク] を使用して、ケースごとに1つの明確な名前を付けたテストを作成してください。

テストを生成する。実行してみて、正当な理由で失敗するテストを手元に残しましょう。

気難しいシニアエンジニアのコードレビュー

Grok は、あらゆるバグを経験してきたベテランレビュアーの役割もこなします。厳しさは歓迎ですが曖昧さは不要なので、該当する行番号を明記させましょう。

口うるさいけれど公平なシニアエンジニアとして、この差分をレビューしてください。バグ、不明瞭な命名、エラーハンドリングの欠落、半年後に問題になりそうな点を、該当行番号と改善案付きで指摘してください。問題は深刻度順に並べ、単なるスタイルの細かな指摘は省いてください：[差分を貼り付け]

チームメンバーに見せる前に、レビューを依頼してみましょう。

スキーマから SQL と README を作成

テーブル定義と取得したいデータを日常的な言葉で伝え、クエリとともに簡潔な解説を求めます。

[PostgreSQL など、データベース名] のテーブル定義です：[スキーマを貼り付け]。[取得したいデータの内容を日常的な言葉で記述] を返すクエリを書いてください。各結合やフィルターについて1行で解説し、テーブルが数百万行になった際に高速化できるインデックスも教えてください。

クエリを作成する。作成後は、テーブルを解説する README のセクションも書いてもらいましょう。

注意すべきこと

• 機密情報を貼り付けない。 API キー、パスワード、トークン、顧客データはチャットに入力してはいけません。プレースホルダーに置き換えてください。
• ライブラリの詳細を鵜呑みにしない。 各モデルには知識のカットオフがあり、ネットアクセスもありません。関数やオプションが古かったり、実在しない架空のものである可能性があります。必ず公式ドキュメントで確認してください。
• テストなしで本番投入しない。 パッと見で正しそうに見えるコードでも動かないことがあります。必ず実行し、テストし、レビューを行ってください。
• リポジトリ全体を送信しない。 長すぎるメッセージは切り捨てられます。問題となっている重要な関数に絞って送信してください。

関連ページ

• コーディングプロンプト集：さらに20パターンの活用例を紹介。
• Grok でのコーディングガイドと推論モデルの解説。
• 自作アプリの開発をご検討中ですか？Grok API についてご覧ください。