Grok Guide
XnoteCONTACTGrokを開く
コース05 / レッスン05 · 公開中

Grok Buildで実装と検証を進める

本文 約2,400文字 · 2026年10月18日確認

このレッスンでできるようになること

Grok Buildへ開発を任せるときも、何を変え、何で完成を確認するかは必要です。動く画面ができたことと、既存の機能を壊さず使えることは同じではありません。このレッスンでは、練習用サイトに検索欄を追加する例で、準備、依頼、差分確認、テスト、引き継ぎを学びます。最後には、変更範囲と検証結果を読んで採用を判断できるようになります。

1.作業用の環境を準備する

Grok Buildの導入は公式のGetting Startedで、使うOSに対応した方法を確認します。教材の古いコマンドを無条件に実行するより、現在の公式配布元と手順を確認してください。導入後は練習用のプロジェクトフォルダーでgrokを起動し、案内に従って認証します。

最初は、重要な本番環境ではなく、小さなサイトや複製した練習用プロジェクトを使います。バージョン管理をしている場合は、作業前の差分を確認し、自分や他の人の未保存・未コミットの変更がないか把握します。既存の変更を勝手に消して始めないことが大切です。

実行するコマンドや外部接続の権限も確認します。ファイルを読む作業、依存関係を追加する作業、公開する作業は影響が違います。今回はローカルのサイトを変更するだけで、外部公開やデータベース更新は含めません。

2.まず既存構造を読ませる

最初の依頼は、すぐ実装させるより、ページの構成、使われている技術、確認方法を説明してもらうことから始めます。READMEやAGENTS.mdなど、プロジェクトのルールがある場合は参照させます。どのファイルが正本で、どれが生成物かを確認してください。

生成されたファイルだけを手で直すと、次のビルドで変更が消える場合があります。編集する元ファイルと生成コマンドを把握することは、保守できる変更を作るために重要です。説明を受け取ったら、実際のファイル名と一致するかを確認します。

使っていないフレームワークを新たに追加するなど、依頼と関係の薄い変更が提案された場合は、必要性を確認します。小さな検索機能なら、既存の仕組みで実装できる可能性があります。目的に対して変更が大きくなりすぎないようにします。

3.完成条件を利用者の動作で書く

検索欄の完成条件は、入力すると関連ページが表示される、結果を選ぶと該当ページが開く、一致しなければその状態が分かる、入力を消すと通常表示へ戻る、という動作です。「検索機能を追加」だけより、確認する場面が明確になります。

日本語の長いタイトルや、空欄、該当なし、狭い画面でも試す条件を含めます。画面の見た目を指定する場合は、既存の文字、色、余白を尊重することも伝えます。新しい部品だけが別のサイトのようにならないようにします。

この練習用サイトにページ検索を追加してください。先にREADMEとAGENTS.md、既存の検索やビルド処理を確認し、編集する正本を説明してください。条件は、日本語タイトルを検索できる、結果からページへ移動できる、一致なしを表示する、入力を消すと戻る、キーボードで操作できることです。既存の構成とデザインを使い、依頼外の大きな改修や外部公開は行いません。実装後は変更ファイル、確認した操作、未確認の範囲を示してください。私や他の人の既存変更を取り消さないでください。

4.差分を読んで目的との関係を確認する

作業が終わったら、返答だけでなく差分を見ます。追加されたファイル、変更された設定、削除された処理が、依頼と関係しているか確認します。検索の追加なのに認証や公開設定が変わっていれば、理由を確認する必要があります。

コードの細部をすべて理解できなくても、入力がどこへ渡り、結果がどこへ表示されるかを説明してもらえます。外部のサービスへ検索語を送る設計なら、その必要性とデータの扱いも確認します。ローカルで完結する設計と同じものとして扱わないでください。

レビューで見つかった問題は、場所、再現方法、期待する動作を伝えます。「動かない」だけでは、画面幅や入力条件を再現できません。具体的な検索語と結果を添えると、修正後の確認も容易になります。

5.正常系と失敗時の両方を試す

まず存在するページ名で検索し、結果のリンクを開きます。次に存在しない語、空欄、長い日本語を試します。スマートフォンに近い幅でも、入力欄が切れず、結果が読めるか確認します。マウスだけでなく、TabとEnterで主要な操作ができるかも見ます。

自動テストやビルドが成功しても、実際の表示を見たことにはなりません。逆に、画面が表示されても内部リンクが壊れている場合があります。機械的な検査と、利用者の操作を確かめる検査を組み合わせます。

修正が入った場合は、その問題と影響する周辺を再確認します。毎回すべてを無目的に繰り返すのではなく、変更で壊れる可能性のある範囲を考えます。失敗が直ったことと、以前動いていた機能が保たれていることを確認してください。

6.採用する版と検証結果を残す

完成時には、変更内容、実施した確認、残る制約を記録します。バージョン管理を使う場合は、どの版が検証対象か分かるようにします。公開するなら、検証した版と実際に公開する版が同じであることを確認します。

「テスト済み」とだけ書かず、検索一致、該当なし、前後移動など何を確認したかを示します。外部サービスへ接続していないなら、その範囲も明記します。別の担当者が続けるときに、どこから確認すればよいか分かる納品にします。

実践課題と完了チェック

練習用サイトで小さな変更を一つ依頼し、差分と動作を確認してください。正本を編集している、完成条件に対応する確認がある、依頼外の変更がない、検証した版を特定できる、という四点が基準です。これで全コースの学習は完了です。実務では小さく試し、根拠と成果を確認し、使える手順を必要な範囲へ広げていきましょう。

出典・補足

操作と仕様は以下の公式資料に基づきます。設計案・練習課題・確認方法は本ガイドの提案です。製品実機での全操作と課金APIへの接続は未検証です。画面・提供条件は利用環境で確認してください。