https://www.knightli.com/ja/tags/%E9%96%8B%E7%99%BA%E5%8A%B9%E7%8E%87/ Recent content in 開発効率 on KnightLiブログ Hugo -- gohugo.io ja Thu, 16 Apr 2026 17:47:17 +0800 https://www.knightli.com/ja/2026/04/16/vscode-claude-api-coding-workflow/ Thu, 16 Apr 2026 17:47:17 +0800 https://www.knightli.com/ja/2026/04/16/vscode-claude-api-coding-workflow/ <p>大規模言語モデルを日常の開発に取り入れ始めると、最初に変わるのは「コードが書けるかどうか」よりも、「細かく散らばった作業をまとめて前に進められるかどうか」です。</p> <p>こうしたツールの価値は、数行補完してくれることだけではありません。エディタの中で対話しながら、ファイルを編集し、結果を確認し、そのまま次の修正に進めることにあります。簡単なページ作成、プロトタイプ検証、見た目の調整、小さな機能追加では、この流れのほうが手作業で行き来するより自然に感じられることが多いです。</p> <p>この記事では、<code>VS Code</code> に <code>Claude</code> 系モデルを接続したあと、実際にページ生成や小さな機能改善へどう活かすかを整理します。</p> <h2 id="1-まずはツールチェーンをつなぐ">1. まずはツールチェーンをつなぐ </h2><p>この種の AI コーディングプラグインの基本的な流れはだいたい同じです。</p> <ol> <li><code>VS Code</code> に対話型コード編集に対応したプラグインを入れる</li> <li>モデルサービスの <code>Base URL</code> を設定する</li> <li>自分の <code>API Key</code> を登録する</li> <li>使用するモデル名を選ぶ</li> </ol> <p>ここまで終わってはじめて、エディタ内の AI 機能が実用段階に入ります。その後の使い勝手の差は、「使えるかどうか」よりも、「モデルの品質はどうか」「対話の体験が自然か」「生成結果が安定しているか」に出やすいです。</p> <p>初めて設定する場合は、次のように考えると分かりやすいです。</p> <ul> <li>プラグインは自然言語の依頼をエディタ上の操作に変換する</li> <li><code>API</code> はその依頼をモデルサービスへ送る</li> <li>モデルは意図を解釈してコードや修正案を返す</li> </ul> <p>つまり、実際に合わせるべき要素は、プラグイン、接続先 URL、モデル名の 3 つです。</p> <h2 id="2-最初は小さなタスクから始める">2. 最初は小さなタスクから始める </h2><p>最初から「丸ごと 1 つのプロジェクトを作ってほしい」と考える人は多いですが、期待値をうまく作るには、むしろ小さなタスクから始めるほうが現実的です。</p> <p>たとえば:</p> <ul> <li>シンプルなフロントエンドページを作る</li> <li>既存ページにお知らせ欄を追加する</li> <li>登録フォームを足す</li> <li>UI を少し整えて、より正式な見た目にする</li> </ul> <p>こうしたタスクが向いている理由は次の通りです。</p> <ul> <li>指示が明確で、モデルが理解しやすい</li> <li>結果をすぐにプレビューできる</li> <li>対話とコード修正の連動が見えやすい</li> </ul> <p>要求が具体的であれば、プラグインはサイドバーで会話しながら、同時にファイルも編集してくれます。その後で結果を見て、ページを確認し、次の要望を足す。このリズムは、単なるチャットより実際の作業に近いものです。</p> <h2 id="3-本当の効率化は一発生成ではなく継続的な反復にある">3. 本当の効率化は一発生成ではなく継続的な反復にある </h2><p>AI コーディングで誤解されやすいのは、「最初の生成結果がどれだけすごいか」に意識が寄りすぎることです。</p> <p>実際に重要なのは、2 回目、3 回目の修正でもちゃんと前に進めるかどうかです。</p> <p>よくある流れはこうです。</p> <ol> <li>まず動くページの土台を作らせる</li> <li>そのあとで 1 つか 2 つ機能を追加する</li> <li>コードと UI が一緒に整っていくかを見る</li> </ol> <p>ツールの体験が良ければ、とても仕事の速いジュニア開発者と組んでいる感覚に近くなります。</p> <ul> <li>こちらが要件を伝える</li> <li>まず 1 版目が出る</li> <li>足りない点を指摘する</li> <li>そのまま修正が続く</li> </ul> <p>こうした対話ベースの反復こそが、実際の開発に近く、効率差が出やすい部分です。</p> <h2 id="4-ai-に任せる部分と自分で直したほうが早い部分を分ける">4. AI に任せる部分と自分で直したほうが早い部分を分ける </h2><p>ここもかなり大事です。</p> <p>ページレイアウト、コンポーネントの初稿、フォームの骨組み、スタイルの整え、仮の文言、繰り返しが多いコードは、AI に任せやすい領域です。</p> <p>一方で、次のような小さな変更だけなら:</p> <ul> <li>ボタン文言を 1 行変える</li> <li>フッターの説明を少し直す</li> <li>ほんの小さなスタイルを調整する</li> </ul> <p>自分でその場で直したほうが速いことが多いです。そこまで小さい変更なら、改めてモデルに依頼するコストのほうが大きくなりやすいからです。</p> <p>効率のよい使い方は、「全部 AI に任せること」ではなく、「大きな塊は任せる、小さな仕上げは自分でやる」と切り分けることです。</p> <h2 id="5-api-設定は最初の壁だが本質的には難しくない">5. API 設定は最初の壁だが、本質的には難しくない </h2><p>つまずく人の多くは、コーディングそのものではなく設定で止まります。</p> <p>確認すべき点はだいたい次の通りです。</p> <ul> <li>接続先 URL が正しいか</li> <li>キーが有効か</li> <li>モデル名がサービス側と一致しているか</li> <li>プラグインが特定の <code>Base URL</code> 形式を要求していないか</li> </ul> <p>このどれかがずれると、プラグイン自体は開いていても、実際のリクエストだけ失敗することがあります。</p> <p>そのため、うまく動かないときの確認順としては:</p> <ol> <li>URL を確認する</li> <li>キーを確認する</li> <li>モデル名と URL 形式を確認する</li> </ol> <p>この順番で見れば、多くの接続トラブルは素早く切り分けられます。</p> <h2 id="6-生成結果を使い続ける価値があるかどうか">6. 生成結果を使い続ける価値があるかどうか </h2><p>見るべきなのは「派手かどうか」ではなく、次の点です。</p> <ul> <li>生成されたページがすぐ動くか</li> <li>構造がある程度わかりやすいか</li> <li>追加の指示を出しても大きく逸れないか</li> <li>修正範囲が広がっても一貫性を保てるか</li> </ul> <p>1 回か 2 回の往復で、真っ白な状態から「ここから育てられるページ」まで進むなら、そのツールには十分な実用性があります。</p> <p>逆に毎回大きく手直しが必要なら、効率化ではなく、単に「コードを書く」作業が「コードをレビューする」作業に置き換わっているだけです。</p> <h2 id="まとめ">まとめ </h2><p><code>VS Code</code> で <code>Claude</code> 系モデルを使う魅力は、「もうコードを書かなくてよくなること」ではありません。散らばっていて反復的で、思考を止めやすい作業をまとめて前に進められることです。</p> <p>より現実的な使い方は次のような形です。</p> <ul> <li>まず AI にページや機能の土台を作らせる</li> <li>2 回か 3 回の対話で磨き込む</li> <li>最後の細かな確定修正は自分で行う</li> </ul> <p>この形なら、AI は開発をすべて置き換える存在ではなく、作業を加速する相棒として機能します。</p>