VS Code on KnightLiブログ

VS Code の表示言語を切り替える方法：中国語、英語、その他の言語

Fri, 08 May 2026 13:18:57 +0800

VS Code は多くの表示言語に対応しています。一般的には、対象の言語パックを先にインストールし、その後コマンドパレットから表示言語を選択します。特定の言語に固定したい場合は、argv.json の locale を手動で変更することもできます。

この方法は簡体字中国語だけでなく、英語、繁体字中国語、日本語、韓国語、フランス語、ドイツ語、スペイン語などにも使えます。

対応する言語パックをインストールする

英語以外のインターフェイスに切り替える場合は、通常、先に言語パックをインストールします。

VS Code 左側の拡張機能パネルを開きます。ショートカット Ctrl+Shift+X も使えます。
検索ボックスに対象言語を入力します。例：Chinese、Japanese、Korean、French。
対応する言語パックを選び、Install をクリックします。
インストール完了後、案内に従って VS Code を再起動します。

簡体字中国語では Chinese (Simplified)、繁体字中国語では Chinese (Traditional) がよく使われます。

コマンドパレットから言語を切り替える

ほとんどのユーザーには、この方法がおすすめです。

コマンドパレットを開きます：Ctrl+Shift+P。
Configure Display Language と入力します。
Configure Display Language コマンドを選択します。
一覧から使用したい言語を選びます。
案内に従って VS Code を再起動します。

再起動後、メニュー、設定画面、一般的なメッセージが選択した言語に切り替わります。対象言語が一覧にない場合は、先に拡張機能パネルから対応する言語パックをインストールしてください。

argv.json で言語を手動指定する

コマンドパレットで切り替えられない場合や、表示言語を明示的に固定したい場合は、VS Code のランタイム引数ファイルを直接編集できます。

コマンドパレットを開きます：Ctrl+Shift+P。
Preferences: Configure Runtime Arguments と入力して選択します。
locale 設定を探すか追加します。
値を対象の言語コードに変更します。
保存して VS Code を再起動します。

英語に切り替える例：

1
2
3

{
  "locale": "en"
}

簡体字中国語に切り替える例：

1
2
3

{
  "locale": "zh-cn"
}

日本語に切り替える例：

1
2
3

{
  "locale": "ja"
}

argv.json は JSON ファイルなので、カンマと引用符に注意してください。設定が間違っていると、VS Code が言語設定を正しく読み取れないことがあります。

よく使う表示言語コード

表示言語	locale
English (US)	`en`
簡体字中国語	`zh-cn`
繁体字中国語	`zh-tw`
French	`fr`
German	`de`
Italian	`it`
Spanish	`es`
Japanese	`ja`
Korean	`ko`
Russian	`ru`
Portuguese (Brazil)	`pt-br`
Turkish	`tr`
Bulgarian	`bg`
Hungarian	`hu`

言語が反映されない場合

次の順番で確認してください。

対象の言語パックがインストール済みか確認します。
locale に正しい言語コードを書いているか確認します。たとえば簡体字中国語は zh-cn で、zh-CN ではありません。
言語を変更した後、VS Code を完全に終了してから再度開きます。
argv.json を手動で編集した場合は、JSON 構文が正しいか確認します。
設定が混乱している場合は、locale 項目を削除してから Configure Display Language で選び直します。

通常は Configure Display Language で切り替えるのが最も簡単です。特定の言語を強制したい場合や、コマンドパレットでの切り替えが反映されない場合だけ、argv.json の手動編集を検討するとよいでしょう。

参考資料

VScode：VS Code の表示言語を簡体字中国語に変更し、表示言語を切り替える

2026年の組み込み開発環境はどう選ぶべきか: Keil、STM32CubeIDE、VS Code、そして AI 協調

Wed, 22 Apr 2026 23:05:00 +0800

マイコンや組み込み開発を続けていると、すぐにひとつの現実的な問いにぶつかります。2026 年になり、AI によるコーディング支援がかなり一般化してきた今、開発環境は結局どう選ぶのがよいのか、という問いです。

表面的にはこれは IDE 同士の比較に見えます。しかし実際に問われているのは別のことです。つまり、単に「プロジェクトを動かせる道具」が欲しいのか、それとも「既存エコシステム、コーディング体験、AI 協調」を両立できるワークフローが欲しいのか、ということです。

その観点で見ると、答えは Keil、STM32CubeIDE、VS Code、CLion のどれかひとつを選ぶことではなく、それぞれが得意な部分を組み直すことになりやすいです。

まず主な選択肢を見て、それぞれ何を解決しているのかを整理する

組み込み分野で長く見かける環境は、だいたい次のようなものです。

Keil
STM32CubeIDE
VS Code
CLion

さらに遡れば IAR を挙げる人もいます。ただ、今の議論で重要なのは「誰が一番古くからあるか」ではなく、「今の開発現実に誰が一番合っているか」です。

Keil: エコシステムは強いが、編集体験は明らかに古い

Keil は今でも避けて通りにくい存在です。理由は単純で、とにかく使われているからです。

会社に残っている古いプロジェクト、オンライン上の教材、サンプルコード、共有されている既存資産の多くが、今でも Keil を中心に組まれています。ビルド、書き込み、デバッグという一連の流れも依然として成熟しており、とにかく基板を動かすことが最優先なら、非常に短い道筋で済みます。

その一方で、弱点もかなりはっきりしています。

UI が古い
編集体験が平凡
AI 支援コーディングの主戦場にはなりにくい

つまり Keil は、「プロジェクトの入口とデバッグ基盤」としては強いものの、2026 年の編集体験を担う理想的な環境とは言いにくいです。

STM32CubeIDE: STM32 には親切だが、どちらかといえば学習と立ち上げ向き

STM32 のエコシステムを主に使っているなら、STM32CubeIDE は最初に触れる環境になりやすいです。

長所は非常にわかりやすいです。

入門しやすい
ペリフェラル設定やプロジェクト生成がしやすい
デバッグ系の流れも比較的そろっている

学生や初心者、立ち上げフェーズのプロジェクトには十分に直感的です。

ただし、長期運用、チーム協業、より複雑なワークフローに入っていくと、徐々に限界が見えてきます。特に商用プロジェクトや重めのチーム開発では、必ずしも最も快適な主環境ではありません。

そのため、これは「すばやく始めるための環境」であって、長期的な主力エディタとは限りません。

VS Code: 厳密には IDE ではないが、AI 時代では優位性が増している

VS Code は厳密には従来型の IDE ではなく、拡張可能なコードエディタです。

だからこそ、最初から二面性があります。

弱点は次の通りです。

プラグインや設定が必要
初心者にはあまり親切ではない
組み込み IDE の全工程をそのまま置き換えるわけではない

しかし、その同じ特徴がそのまま強みにもなります。

拡張性が高い
編集体験がかなり現代的
ハイライト、ジャンプ、検索、リファクタリングが強い
AI ツールや Agent ワークフローとの相性が良い

今や多くの開発者が欲しいのは、単に「コードが書けること」ではなく、「AI 協調を自然に入れられること」です。その意味で、VS Code の優位性はかなり明確です。

CLion: 体験は良いが、組み込みの主流ワークフローの中心ではない

CLion が話題に出ることはよくあります。C/C++ の編集体験が良いからです。

ただ、組み込み開発者にとって本当の問題は「良いか悪いか」より、「移る価値があるか」です。

組み込みでは利用者が比較的少ない
既存の組み込みエコシステムとの接続が Keil ほど直接的ではない
AI 協調という観点でも、VS Code より現実的な優位があるとは限らない

そのため、CLion は「理屈上はかなり良い選択肢」ではあっても、今の組み込み主流ワークフローの自然な中心とは言いにくいです。

より現実的な答え: ビルドとデバッグは Keil、日常のコーディングは VS Code

それぞれの道具を役割ごとに分けて考えると、かなり実務的な結論が見えてきます。

Keil には既存プロジェクト互換、ビルド、書き込み、デバッグを任せる
VS Code には日常のコーディング、検索、ジャンプ、AI 協調を任せる

この組み合わせの価値は、ひとつの道具ですべてをやろうとしない点にあります。それぞれを、本当に得意な位置に戻してあげるわけです。

多くの組み込み案件では、Keil のエコシステム自体を避けることができません。ならば、すべてを Keil に押し込めるより、Keil をビルド・デバッグのバックエンド入口と割り切り、実際の編集体験は VS Code に任せる方が自然です。

なぜこの組み合わせが AI 時代に向いているのか

今や環境の違いは、「エディタが気持ちよく使えるか」だけではありません。「AI を自然に接続できるか」が大きな分かれ目です。

VS Code にはこの点でかなり実務的な強みがあります。

AI プラグインや Agent の動きが活発
AI がプロジェクトを読み、変更するのに向いた閲覧体験
現代的なプラグイン群と組み合わせやすい

つまり、組み込み開発で面倒になりがちな作業の一部を AI に肩代わりさせやすくなります。

既存プロジェクト内の関数や呼び出し関係を探す
初期化コードを素早く生成する
簡単な UART 出力を足す
古いプロジェクト構造を説明させる
既存ファイルの一部だけを小さく直す

こうしたことは昔も不可能ではありませんでした。ただ、とにかくやりにくかったのです。VS Code の価値は、見た目がよいことではなく、AI 協調の作業台になりやすいことです。

重要な補助線: プラグインで VS Code と Keil プロジェクトをつなぐ

このワークフローが現実に機能するかどうかは、VS Code と Keil プロジェクトをつなげられるかにかかっています。

実用的な方向性のひとつは、VS Code から Keil のプロジェクト構造を読み取り、エディタ内部から Keil のバックエンドを呼び出して次のような操作を行えるようにすることです。

プロジェクトを開く
ビルドする
書き込む

そうすれば、日常のコーディングで二つの画面を行ったり来たりする必要が減ります。重いデバッグ、つまりステップ実行、ブレークポイント、レジスタ確認が必要なときだけ Keil に戻ればよくなります。

この種のプラグインの価値は、単に画面切り替えが減ることではありません。ワークフロー自体を途切れさせないことにあります。

C/C++ の基本プラグイン設定を軽視しない

VS Code を組み込みの主エディタとして使うなら、見落とされがちですが非常に重要な点があります。C/C++ の基本プラグインとプロジェクト索引をきちんと設定することです。

これが整っていないと、体験を壊す問題が次々に起きます。

定義ジャンプが効かない
赤線の誤検知が多い
補完の精度が低い
ヘッダ関係が崩れる

この状態を見て、「やはり VS Code は組み込みに向かない」と判断してしまう人もいます。ですが実際には、プラグインと索引の接続が不十分なだけであることが少なくありません。

この部分がきちんと整えば、VS Code は大規模プロジェクトの読解、シンボル検索、AI を使った局所的なコード修正でかなり強さを発揮します。

このワークフローが特に向いている人

この組み合わせは、特に次のような人に向いていると思います。

1. すでに Keil ベースの資産が大量にある人

会社の案件、教材、過去コードがすべて Keil 中心なら、見た目を現代化したいだけでその資産を捨てる必要はありません。Keil を残し、VS Code を前段に足す方が、移行コストははるかに低いです。

2. AI に組み込みコードを手伝ってもらいたい人

関数の説明、ひな形コードの生成、局所ロジックの修正などを AI に任せたいなら、従来型の組み込み IDE より VS Code の方が自然にその役割を引き受けやすいです。

3. 学習資料と実案件の両方をつなぎたい人

学習資料は今でも Keil ベースのものが多いですが、自分の作業環境までその時代に留まる必要はありません。Keil を互換層、VS Code を生産性層として分けて考える方が、全体としてバランスが取れます。

結び

2026 年の組み込み開発環境で本当に問われているのは、「どの IDE が最も多機能か」ではなく、「どの組み合わせが今の仕事のしかたに最も合っているか」です。

素早く始めたいだけなら STM32CubeIDE には今でも価値があります。大量の既存資産を受け継ぐなら Keil は依然として避けられません。ですが、現代的な編集体験と AI 協調まで取り込みたいなら、より現実的な答えは次の形になりやすいです。

Keil にビルドとデバッグを任せ、VS Code にコードを書く仕事を任せる。

唯一の正解ではないとしても、今ある選択肢の中ではかなり無理の少ない答えだと思います。

VS Code に Claude を接続する: API 設定からページ生成まで

Thu, 16 Apr 2026 17:47:17 +0800

大規模言語モデルを日常の開発に取り入れ始めると、最初に変わるのは「コードが書けるかどうか」よりも、「細かく散らばった作業をまとめて前に進められるかどうか」です。

こうしたツールの価値は、数行補完してくれることだけではありません。エディタの中で対話しながら、ファイルを編集し、結果を確認し、そのまま次の修正に進めることにあります。簡単なページ作成、プロトタイプ検証、見た目の調整、小さな機能追加では、この流れのほうが手作業で行き来するより自然に感じられることが多いです。

この記事では、VS Code に Claude 系モデルを接続したあと、実際にページ生成や小さな機能改善へどう活かすかを整理します。

1. まずはツールチェーンをつなぐ

この種の AI コーディングプラグインの基本的な流れはだいたい同じです。

VS Code に対話型コード編集に対応したプラグインを入れる
モデルサービスの Base URL を設定する
自分の API Key を登録する
使用するモデル名を選ぶ

ここまで終わってはじめて、エディタ内の AI 機能が実用段階に入ります。その後の使い勝手の差は、「使えるかどうか」よりも、「モデルの品質はどうか」「対話の体験が自然か」「生成結果が安定しているか」に出やすいです。

初めて設定する場合は、次のように考えると分かりやすいです。

プラグインは自然言語の依頼をエディタ上の操作に変換する
API はその依頼をモデルサービスへ送る
モデルは意図を解釈してコードや修正案を返す

つまり、実際に合わせるべき要素は、プラグイン、接続先 URL、モデル名の 3 つです。

2. 最初は小さなタスクから始める

最初から「丸ごと 1 つのプロジェクトを作ってほしい」と考える人は多いですが、期待値をうまく作るには、むしろ小さなタスクから始めるほうが現実的です。

たとえば:

シンプルなフロントエンドページを作る
既存ページにお知らせ欄を追加する
登録フォームを足す
UI を少し整えて、より正式な見た目にする

こうしたタスクが向いている理由は次の通りです。

指示が明確で、モデルが理解しやすい
結果をすぐにプレビューできる
対話とコード修正の連動が見えやすい

要求が具体的であれば、プラグインはサイドバーで会話しながら、同時にファイルも編集してくれます。その後で結果を見て、ページを確認し、次の要望を足す。このリズムは、単なるチャットより実際の作業に近いものです。

3. 本当の効率化は一発生成ではなく継続的な反復にある

AI コーディングで誤解されやすいのは、「最初の生成結果がどれだけすごいか」に意識が寄りすぎることです。

実際に重要なのは、2 回目、3 回目の修正でもちゃんと前に進めるかどうかです。

よくある流れはこうです。

まず動くページの土台を作らせる
そのあとで 1 つか 2 つ機能を追加する
コードと UI が一緒に整っていくかを見る

ツールの体験が良ければ、とても仕事の速いジュニア開発者と組んでいる感覚に近くなります。

こちらが要件を伝える
まず 1 版目が出る
足りない点を指摘する
そのまま修正が続く

こうした対話ベースの反復こそが、実際の開発に近く、効率差が出やすい部分です。

4. AI に任せる部分と自分で直したほうが早い部分を分ける

ここもかなり大事です。

ページレイアウト、コンポーネントの初稿、フォームの骨組み、スタイルの整え、仮の文言、繰り返しが多いコードは、AI に任せやすい領域です。

一方で、次のような小さな変更だけなら:

ボタン文言を 1 行変える
フッターの説明を少し直す
ほんの小さなスタイルを調整する

自分でその場で直したほうが速いことが多いです。そこまで小さい変更なら、改めてモデルに依頼するコストのほうが大きくなりやすいからです。

効率のよい使い方は、「全部 AI に任せること」ではなく、「大きな塊は任せる、小さな仕上げは自分でやる」と切り分けることです。

5. API 設定は最初の壁だが、本質的には難しくない

つまずく人の多くは、コーディングそのものではなく設定で止まります。

確認すべき点はだいたい次の通りです。

接続先 URL が正しいか
キーが有効か
モデル名がサービス側と一致しているか
プラグインが特定の Base URL 形式を要求していないか

このどれかがずれると、プラグイン自体は開いていても、実際のリクエストだけ失敗することがあります。

そのため、うまく動かないときの確認順としては:

URL を確認する
キーを確認する
モデル名と URL 形式を確認する

この順番で見れば、多くの接続トラブルは素早く切り分けられます。

6. 生成結果を使い続ける価値があるかどうか

見るべきなのは「派手かどうか」ではなく、次の点です。

生成されたページがすぐ動くか
構造がある程度わかりやすいか
追加の指示を出しても大きく逸れないか
修正範囲が広がっても一貫性を保てるか

1 回か 2 回の往復で、真っ白な状態から「ここから育てられるページ」まで進むなら、そのツールには十分な実用性があります。

逆に毎回大きく手直しが必要なら、効率化ではなく、単に「コードを書く」作業が「コードをレビューする」作業に置き換わっているだけです。

まとめ

VS Code で Claude 系モデルを使う魅力は、「もうコードを書かなくてよくなること」ではありません。散らばっていて反復的で、思考を止めやすい作業をまとめて前に進められることです。

より現実的な使い方は次のような形です。

まず AI にページや機能の土台を作らせる
2 回か 3 回の対話で磨き込む
最後の細かな確定修正は自分で行う

この形なら、AI は開発をすべて置き換える存在ではなく、作業を加速する相棒として機能します。

WindowsでVS CodeからDockerイメージをビルドする方法

Thu, 16 Apr 2026 10:20:00 +0800

Windows環境でVS CodeからDockerイメージを作る流れはシンプルです。基本は3ステップだけです。環境準備、Dockerfile作成、イメージビルドの順で進めます。

01 事前準備

まず次の2点を確認します。

Docker Desktopをインストールし、起動しておく。
VS CodeでMicrosoft公式のDocker拡張機能を入れる。

WindowsではDocker DesktopのWSL 2バックエンド（Settings > Resources > WSL Integration）を使うと、安定性と速度の面で有利です。

02 Dockerfileを用意する

まだDockerfileがない場合は、VS Codeで自動生成できます。

VS Codeでプロジェクトフォルダを開く。
F1またはCtrl+Shift+Pでコマンドパレットを開く。
Docker: Add Docker Files to Workspaceを実行する。
Node.js、Python、.NETなど対象プラットフォームを選び、案内に従う。

通常は次のファイルが生成されます。

Dockerfile
.dockerignore

まずは動く雛形を作り、あとで調整するのが効率的です。

03 イメージをビルドする3つの方法

方法A: Dockerfileを右クリック

エクスプローラーでDockerfileを右クリックし、Build Image...を選択してタグ名を入力します。

方法B: コマンドパレット

F1でDocker: Build Imageを実行し、コンテキストとタグを選びます。

方法C: 統合ターミナル

`1`	`docker build -t your-image-name .`

現在のディレクトリをビルドコンテキストとして、your-image-nameタグでイメージを作成します。

04 よくある問題の確認ポイント

Docker Desktopが起動していない: 先に起動状態を確認する。
ビルドが遅い: WSL 2バックエンドが有効か確認する。
ファイルが見つからないエラー: 実行場所がプロジェクトルートか確認する。
VS CodeでDocker項目が出ない: VS Code再起動とdocker version確認を行う。

まとめ

WindowsでVS CodeからDockerイメージを作る作業は、初期セットアップができれば難しくありません。Docker Desktopと拡張機能を整え、必要ならDockerfileを自動生成し、UIまたはdocker buildでビルドすれば運用できます。

エージェントスキルを使用して、VS Code の Copilot の「コミットメッセージの生成」機能を置き換える

Mon, 06 Apr 2026 13:09:49 +0800

VS Code の GitHub Copilot の「コミットメッセージの生成」は非常に便利な機能です。クォータを使い果たした後のリセット期間は非常に長くなります。この記事は、ローカルエージェントスキルを使用してこの機能を置き換える試みです。

問題と目標

この記事の目的は、直接実装できる代替手段のセットを提供することです。つまり、git-commit-push-zh スキルエージェントを使用して、標準化された送信とプッシュを完了します。

代替: `git-commit-push-zh`

このスキルは、「現在の変更」を固定プロセスに収束します。

変更ステータスを表示します。
現在のブランチを確認します。
変更を一時的に保存します。
中国語の提出情報を生成します。
コミットを実行します。
リモートブランチにプッシュします。

対応するコマンドは次のとおりです。

git status --short
git branch --show-current
git add -A
git commit -m "<中文提交信息>"
git push origin <当前分支>

情報提案仕様書の提出

推奨される統一形式:

`1`	`<类型>(<范围>): <中文摘要>`

タイプの例:

feat: 新機能
fix: 問題を修正
docs: ドキュメントの更新
refactor: コードのリファクタリング
chore: メンテナンスの変更

例：

feat(site): 新增全站 head 广告脚本注入
fix(i18n): 修正 relref 相关文章链接路径
chore(content): 合并 AI 工作流分类到 AI工具

一般的な障害シナリオ

nothing to commit: 現在、送信する変更はありません。プッシュを停止してください。
push が失敗しました: 最初に権限、リモートブランチのステータス、競合を確認してください。
SSH/権限の例外: 認証情報と権限を確認して、再試行してください。

付録: オリジナル `SKILL.md`

次の内容は git-commit-push-zh の元のドキュメントであり、その後の再利用とメンテナンスを容易にするためにそのまま保持されます。

---
name: git-commit-push-zh
description: 在当前 Git 仓库中将“当前更改”完成一次标准提交流程：检查状态、暂存变更、生成中文提交信息、执行 commit 并 push 到当前分支对应远端。用户提出“提交代码”“提交当前更改”“生成中文提交信息并推送”“git commit push 中文说明”等请求时使用。
---

# 中文提交并推送

使用此技能将当前仓库改动一次性提交并推送到远端。

## 工作流程

1. 查看变更状态：`git status --short`。
2. 确认当前分支：`git branch --show-current`。
3. 暂存当前变更：`git add -A`。
4. 生成中文提交信息（简洁、可检索）。
5. 执行提交：`git commit -m "<中文提交信息>"`。
6. 执行推送：`git push origin <当前分支>`。

## 提交信息规范（中文）

1. 建议格式：`<类型>(<范围>): <中文摘要>`。
2. 类型示例：`feat`、`fix`、`chore`、`docs`、`refactor`。
3. 摘要要求：准确描述本次改动，不写空话。
4. 若仅少量变更，也保持可读性与可检索性。

示例：

- `feat(site): 新增全站 head 广告脚本注入`
- `fix(i18n): 修正 relref 相关文章链接路径`
- `chore(content): 合并 AI 工作流分类到 AI工具`

## 错误处理

1. 若无可提交变更（nothing to commit），明确告知并停止 push。
2. 若 push 失败，先回报关键错误（权限、远端不存在、冲突等）。
3. 常见 SSH/权限问题可在用户确认后重试高权限环境。

## 输出约定

1. 汇报提交哈希、分支名、提交信息。
2. 汇报 push 结果（成功或失败原因）。
3. 仅在确有失败时提供下一步最小操作建议。

プラグインによって引き起こされる VS Code の高い CPU 使用率をトラブルシューティングする方法

Wed, 01 Apr 2026 00:00:00 +0000

VS Code が突然フリーズしたり、ファンが激しく回転したり、CPU が長時間占有されたりした場合、最も一般的な原因は通常、エディタ自体ではなく、拡張プラグインの競合またはプラグインの異常な動作です。

この記事では、問題を特定するために最も時間を節約できる方法を優先して、すぐに実行できる一連のトラブルシューティングパスを示します。

最初に最速の位置決めを実行します: Extension Bisect を開始します

Start Extension Bisect の核となるアイデアは次の二項対立です。各ラウンドでは、拡張機能の半分が一時的に無効になり、再起動されます。「問題がまだ存在するかどうか」というフィードバックを通じて、疑わしいプラグインが見つかるまで範囲がすぐに狭められます。

操作手順:

Ctrl+Shift+P (macOS では Cmd+Shift+P) を押してコマンドパネルを開きます。
Start Extension Bisect を入力して実行します。
再起動するたびに、CPU 使用率とフリーズが再発するかどうかを観察します。
数回繰り返すと、VS Code によって疑わしい拡張機能のリストが表示されます。

位置決め後に何をするか

疑わしいプラグインを見つけたら、次の順序で対処することをお勧めします。

まずプラグインを最新バージョンに更新してください。
改善が見られない場合は、プラグインを一時的に無効にして 1 ～ 2 日間観察してください。
置き換え可能な機能を持つプラグインについては、より軽量なソリューションへの置き換えが優先されます。
このプラグインを使用する必要がある場合は、その詳細設定を確認し、不要なリアルタイム分析、インデックス作成、または監視機能をオフにしてください。

見落とされがちな2つの「増幅器」

主な原因がプラグインである場合でも、次の構成により CPU の問題が増幅されます。

検索範囲が大きすぎます
たとえば、ビルド製品、依存関係ディレクトリ、ログディレクトリをグローバル検索に含めると、引き続きプラグインとファイルインデックスに高い負荷がかかります。
ファイル監視には大きなディレクトリまたはソフトリンクが含まれています
ソフトリンク、キャッシュディレクトリ、および自動生成されたディレクトリは、簡単に多数のファイルイベントをトリガーし、拡張機能が繰り返し動作する可能性があります。

ディレクトリは、settings.json で適切に除外できます。たとえば、次のようになります。

{
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/build": true
  },
  "files.watcherExclude": {
    "**/.git/objects/**": true,
    "**/node_modules/**": true,
    "**/dist/**": true
  }
}

提案をレビューする

問題のあるプラグインを見つけた場合は、プラグイン名、トリガーとなるシナリオ、最終的な処理方法の 3 つの情報を記録することをお勧めします。
このようにして、次回環境を移行するかシステムを再インストールするときに、同様の問題をすぐに回避できます。

要約する

VS Code の高い CPU 使用率をトラブルシューティングするには、最初に Start Extension Bisect を使用して迅速に特定し、次に検索範囲とファイル監視範囲を組み合わせて収束させるのが最も効果的です。
最初に配置を決めてから最適化する方が、「多数のプラグインをやみくもに無効にする」よりも時間を節約でき、安定性も高くなります。

VS CodeでCodexを使う方法（インストールから効率的な実践まで）

Fri, 20 Mar 2026 00:00:00 +0000

Codex は、コードの作成、バグの修正、プロジェクトの説明、VS Code サイドバーでのコマンドの直接実行に役立ちます。

1. 準備

始める前に、次のことを確認してください。

VS Code は新しい安定バージョンに更新されました。
OpenAi Web サイトには通常どおりアクセスできます
プロジェクトコードはローカルで開かれています (Git リポジトリが推奨されます)。

2. 拡張機能をインストールする

VS Code 拡張機能マーケット (Extensions) をオープンします。
Codex - Codex - OpenAI's coding agent を検索してインストールします。
インストールが完了したら、プロンプトに従ってログイン認証を完了します。

3.コーデックスのサイドバーを開きます

任意の方法で開くことができます。

エディターの右上隅にある Open Codex Sidebar をクリックします。
コマンドパネル (Ctrl + Shift + P) を使用して、Codex を検索して開きます。

Codex を開いた後、現在のワークスペースコンテキストを読み取り、会話状態に入ります。

4. 一般的な使用方法

4.1 コードを解釈させる

プロンプトの単語の例:

`1`	`请解释这个文件的核心逻辑，并指出最可能出错的 3 个地方。`

古いプロジェクトを引き継ぐ場合に、グローバルな理解を迅速に確立するのに適しています。

4.2 機能させる

プロンプトの単語の例:

1
2

在现有 API 里新增一个 /healthz 健康检查接口，
要求返回版本号和数据库连接状态，并补上基础测试。

生成される結果がより安定するように、「入力制約」と「受け入れ基準」を一緒に明確に記述することをお勧めします。

4.3 問題を解決してもらう

プロンプトの単語の例:

1
2

这个接口在并发下偶发 500，请先定位根因，再给出最小改动修复方案，
最后列出回归测试点。

最初に「位置を特定」してから「修復」することで、誤った修正や過度の再構築を減らすことができます。

5. 高品質のプロンプト Word テンプレート

次の構造を直接再利用できます。

背景：这是一个 <技术栈> 项目，当前目标是 <目标>
约束：不改动 <模块/接口>，兼容 <版本/平台>
输出：
1) 修改文件列表
2) 关键代码说明
3) 验证步骤
4) 风险与回滚方案

このテンプレートは、「複数人でのコラボレーション + 大規模プロジェクト」に非常に役立ちます。

6. よくある質問

6.1 無料割り当てについて

ダイアログボックスに「\」と入力し、ステータスを選択します。クォータ、リセット時間などの関連情報が表示されます。

6.2 変更が期待どおりにならない

変更が完了したら、「レビュー」ボタンをチェックして変更の詳細を表示します。満足できない場合は、「元に戻す」ボタンを選択して変更を元に戻します。次のステップでは、要件を複数のステップに分割して個別に実行できます。 git などのコード管理ツールを使用して、小さなステップでコミットを維持し、ロールバックを容易にします。

VS Code on KnightLiブログ

VS Code の表示言語を切り替える方法：中国語、英語、その他の言語

対応する言語パックをインストールする

コマンドパレットから言語を切り替える

argv.json で言語を手動指定する

よく使う表示言語コード

言語が反映されない場合

参考資料

2026年の組み込み開発環境はどう選ぶべきか: Keil、STM32CubeIDE、VS Code、そして AI 協調

まず主な選択肢を見て、それぞれ何を解決しているのかを整理する

Keil: エコシステムは強いが、編集体験は明らかに古い

STM32CubeIDE: STM32 には親切だが、どちらかといえば学習と立ち上げ向き

VS Code: 厳密には IDE ではないが、AI 時代では優位性が増している

CLion: 体験は良いが、組み込みの主流ワークフローの中心ではない

より現実的な答え: ビルドとデバッグは Keil、日常のコーディングは VS Code

なぜこの組み合わせが AI 時代に向いているのか

重要な補助線: プラグインで VS Code と Keil プロジェクトをつなぐ

C/C++ の基本プラグイン設定を軽視しない

このワークフローが特に向いている人

1. すでに Keil ベースの資産が大量にある人

2. AI に組み込みコードを手伝ってもらいたい人

3. 学習資料と実案件の両方をつなぎたい人

結び

VS Code に Claude を接続する: API 設定からページ生成まで

1. まずはツールチェーンをつなぐ

2. 最初は小さなタスクから始める

3. 本当の効率化は一発生成ではなく継続的な反復にある

4. AI に任せる部分と自分で直したほうが早い部分を分ける

5. API 設定は最初の壁だが、本質的には難しくない

6. 生成結果を使い続ける価値があるかどうか

まとめ

WindowsでVS CodeからDockerイメージをビルドする方法

01 事前準備

02 Dockerfileを用意する

03 イメージをビルドする3つの方法

方法A: Dockerfileを右クリック

方法B: コマンドパレット

方法C: 統合ターミナル

04 よくある問題の確認ポイント

まとめ

エージェント スキルを使用して、VS Code の Copilot の「コミット メッセージの生成」機能を置き換える

問題と目標

代替: git-commit-push-zh

情報提案仕様書の提出

一般的な障害シナリオ

付録: オリジナル SKILL.md

プラグインによって引き起こされる VS Code の高い CPU 使用率をトラブルシューティングする方法

最初に最速の位置決めを実行します: Extension Bisect を開始します

位置決め後に何をするか

見落とされがちな2つの「増幅器」

提案をレビューする

要約する

VS CodeでCodexを使う方法（インストールから効率的な実践まで）

1. 準備

2. 拡張機能をインストールする

3.コーデックスのサイドバーを開きます

4. 一般的な使用方法

4.1 コードを解釈させる

4.2 機能させる

4.3 問題を解決してもらう

5. 高品質のプロンプト Word テンプレート

6. よくある質問

6.1 無料割り当てについて

6.2 変更が期待どおりにならない

エージェントスキルを使用して、VS Code の Copilot の「コミットメッセージの生成」機能を置き換える

代替: `git-commit-push-zh`

付録: オリジナル `SKILL.md`