VS Code 1.126 は、AI開発のコストを「セッション単位」で見せ始めた
2026年6月24日に Visual Studio Code 1.126 が公開されました。公式リリースノートの冒頭では、今回の更新として、コスト透明性、モデル調整の簡素化、未知のコードを安全に見るための Workspace Trust 改善が挙げられています。参考: Visual Studio Code 1.126
今回いちばん実務で効くのは、チャットセッション全体のコストが見えるようになったことです。
これまでも、AI コーディングの利用量や請求額は、管理画面やプラン単位では確認できました。しかし、現場で知りたいのは、もっと細かい単位です。
- この Issue を解くのに、どれくらい AI Credits を使ったのか
- 実装、レビュー、テスト、ドキュメント作成のどこでコストが膨らんだのか
- 高いセッションは、本当に難しい仕事だったのか、それとも進め方が悪かったのか
- 同じ種類のタスクで、どのプロンプトや運用がいちばん費用対効果がよいのか
VS Code 1.126 の Session-level cost information は、この問いにかなり近い場所へ来ています。
Session-level cost - 1ターンではなく、1セッションの総コストを見る
公式リリースノートでは、個別ターンだけでなく、チャットセッション全体のコストを見られるようになったと説明されています。目的は、どのセッションが多くの credits を消費しているかを見つけ、時間をかけて利用量を管理しやすくすることです。参考: Session-level cost information
添付のスクリーンショットでも、Session Info の中に Session Cost 8.3 credits が表示されています。あわせて、コンテキストウィンドウの使用量、System Instructions、Tool Definitions、Messages の比率も見えています。
この表示が良いのは、単に「高い・安い」を見るためではありません。
AI エージェントの仕事は、1 回の応答で完結しません。調査、ファイル読み込み、実装、テスト、レビュー、修正、説明までを 1 つの流れで進めます。個別ターンのコストだけを見ると、全体の仕事量を把握しにくい。
しかし、セッション単位でコストが見えると、1 つの作業単位にかかった AI コストとして扱えます。
これは KPI 算出に向いています。
KPIにするなら、見るべき単位は「会話数」ではなく「成果物あたり」
AI 活用の KPI は、プロンプト数やチャット回数だけでは弱いです。
チャット回数が増えたから生産性が上がったとは限りません。逆に、短いやり取りだけで済んだように見えても、人間が裏で大量に修正していれば効果は低い。AI の利用量だけを見ても、業務成果との接続が見えません。
セッション単位コストが取れるなら、見るべき KPI は次のようになります。
| KPI候補 | 見たいこと |
|---|---|
| Cost per Issue | 1つの Issue を完了するのに必要な AI Credits |
| Cost per PR | 1つの Pull Request を作るまでの AI Credits |
| Cost per accepted diff | 採用された差分あたりの AI Credits |
| Cost per review fix | レビュー指摘を解消するまでの AI Credits |
| Cost per verified change | テストやプレビューで確認済みの変更あたりの AI Credits |
| Cost per documentation update | ドキュメント更新や記事作成あたりの AI Credits |
ここで大事なのは、安ければ良いという話にしないことです。
難しい設計変更、セキュリティ調査、障害調査、移行作業は、コストが高くて当然です。むしろ高いモデルや長いコンテキストを使うことで、手戻りを減らせる場合があります。
見るべきなのは、同じ種類の仕事を、同じ品質で、より再現性高く進められているかです。
例えば、あるチームで次のような傾向が見えたとします。
- 小さな UI 修正は 3〜5 credits で安定している
- 調査込みのバグ修正は 10〜20 credits に収まる
- 仕様が曖昧な Issue は 40 credits を超えやすい
- テスト前提が不足した PR は、レビュー修正でさらに credits を消費する
ここまで見えると、単なる節約ではなく、運用改善に使えます。
仕様が曖昧な Issue は、AI に投げる前に受け入れ条件を整える。レビュー修正が重いなら、最初のプロンプトにテスト観点を入れる。調査だけで膨らむなら、Research 用のセッションと実装用のセッションを分ける。
つまり、Session Cost は「請求の確認」ではなく、AI 開発プロセスの設計指標になります。
Multiple chats per session と組み合わせると、作業単位が見えやすい
1.126 では Agents window も改善されています。Copilot session が agent host から開始されている場合、同じセッション内で複数のチャットを並行して持てるようになりました。一次チャットが実装している間に、別チャットで途中差分のレビュー、テスト作成、ドキュメント作成を進められます。参考: Multiple chats in an agent host Copilot session
これは Session Cost と相性が良いです。
1つの Issue に対して、同じ作業コンテキストの中で次のように役割を分けられます。
- Chat A: 実装
- Chat B: 差分レビュー
- Chat C: テスト観点の洗い出し
- Chat D: ドキュメントや PR 本文の整理
それぞれのチャットは別会話として残りつつ、同じセッションと作業コンテキストを共有します。さらにセッション全体のコストを見られるなら、「この Issue の AI 作業全体で何 credits かかったか」という単位に寄せやすい。
AI 仕様駆動開発では、AI にただコードを書かせるのではなく、仕様、実装、レビュー、検証を一つの流れとして扱います。その意味で、1セッションを「作業単位」として見られることはかなり大きいです。
モデル調整 UI は、コストと品質のトレードオフを扱いやすくする
Language models まわりでは、context size と reasoning effort の調整が、ひとつの model customization picker に統合されました。別々のドロップダウンを触るのではなく、モデル調整の入口をまとめた形です。参考: Unified model customization picker
これは UI の整理に見えますが、Session Cost と一緒に見ると意味が変わります。
AI 開発では、コストを下げるためにコンテキストを削りすぎると、逆に失敗します。仕様、既存コード、制約、テスト結果を渡さないまま進めると、AI はそれらしく実装しても、後で人間が直す時間が増える。
一方で、何でも大きなコンテキスト、強い reasoning、上位モデルにすればよいわけでもありません。小さな修正、既知パターンの反映、文章の整形なら、軽い設定で十分なこともあります。
ここで必要なのは、気分でモデルを選ぶことではなく、タスクごとに実測することです。
| タスク | 試したい見方 |
|---|---|
| 小さな UI 修正 | 低コスト設定でもテストまで通るか |
| 複雑なバグ調査 | reasoning を上げると再質問や手戻りが減るか |
| 大きなリファクタリング | context size を上げる価値が Cost per PR に出るか |
| ドキュメント作成 | 高い設定にしなくても品質が安定するか |
Session Cost が出ると、こうした比較がやりやすくなります。
Workspace Trust の変更は、知らないコードを読むときの安全側デフォルト
Editor experience では、Workspace Trust も改善されています。新しいフォルダを開いたとき、以前のように最初から信頼するか尋ねるダイアログを出すのではなく、Restricted Mode で開き、信頼バナーを表示するようになりました。設定 security.workspace.trust.startupPrompt の既定値も once から never に変わっています。参考: Open new folders in Restricted Mode
また、Workspace Trust editor から Trust Parent ボタンが削除されました。親フォルダごと信頼してしまう操作を、誤って選びにくくするためです。参考: Removed trust parent from the Workspace Trust editor
AI エージェントを使う環境では、この変更も重要です。
未知のリポジトリ、検証用に落としてきたサンプル、顧客から渡されたコード、OSS の調査対象などを開く場面は増えます。そこで最初から信頼済みとして扱うより、Restricted Mode で中身を確認し、必要になったら信頼するほうが安全です。
AI に「このリポジトリを読んで」と依頼する前に、人間側のエディタが安全側に倒れている。これは地味ですが、AI 開発の運用には効きます。
Agentic code feedback は、レビュー指摘をエージェントに渡しやすくする
Agents window では、生成コードに残したコメントが agent host 側に保存され、エージェントが server-side tools を通じて扱えるようになっています。ローカルクライアントから切断してもコメントが agent host に残るため、レビュー指摘を後からエージェントへ渡しやすくなります。参考: Agentic code feedback with agent host harnesses
Pull Request の review comments も同じ流れで扱えます。未承認の PR review comments をエージェントが見る場合は、まず許可を求めると説明されています。
ここも KPI と接続できます。
AI に任せる開発で重要なのは、最初の実装よりも、レビュー後にどれだけ素早く安全に直せるかです。レビュー指摘をエージェントが扱いやすくなると、Cost per review fix を測りやすくなります。
例えば、同じチームで次のように見られます。
- 実装は安いが、レビュー修正が高い
- レビュー指摘の粒度を変えると、修正コストが下がる
- コメントをファイル単位ではなく行単位にすると、エージェントの修正成功率が上がる
- PR 本文に受け入れ条件を明記すると、レビュー修正回数が減る
こうした運用改善は、会話ログだけでは見えにくい。Session Cost とレビュー指摘の流れが近づくことで、やっと数字として見やすくなります。
FEEL-FLOWで試すなら、まずこの計測から始める
1.126 の Session Cost を使うなら、最初から大げさなダッシュボードを作る必要はありません。まずは、1週間だけ次の項目を PR ごとに記録すれば十分です。
| 項目 | 記録する内容 |
|---|---|
| Issue / PR | 対応した Issue 番号、PR 番号 |
| タスク種別 | 実装、バグ修正、記事作成、調査、レビュー対応 |
| Session Cost | VS Code の Session Info に表示された credits |
| 成果 | マージ済み、レビュー待ち、保留、破棄 |
| 検証 | build、test、preview、手動確認の有無 |
| 手戻り | レビュー修正回数、再実装の有無 |
これだけでも、かなり見えてきます。
AI 利用の成熟度は、「どのモデルを使っているか」だけでは決まりません。むしろ、仕様をどう渡すか、レビューをどう返すか、コストをどう見て改善するかで差が出ます。
AI 仕様駆動開発では、仕様、受け入れ条件、検証観点を先に整えます。Session Cost を合わせて見ると、仕様が整っているタスクほど AI コストが安定するか、逆に仕様を厚くしても成果品質が上がるなら妥当か、という判断ができます。
ここが面白いところです。
Session Cost は、AI を節約するためだけの数字ではありません。良い仕様、良いレビュー、良い検証が、どれだけ AI 作業を安定させたかを見る数字にもなります。
まとめ
Visual Studio Code 1.126 は、大きな派手さよりも、AI 開発を運用に落とすための細かい改善が目立つリリースです。
- チャットセッション全体の Session Cost が見えるようになった
- コストを Issue、PR、レビュー修正、検証済み変更あたりの KPI に接続しやすくなった
- Agents window では、同じ session の中で複数チャットを並行して扱える
- モデル調整 UI がまとまり、context size と reasoning effort の調整がしやすくなった
- 新しいフォルダは Restricted Mode で開くようになり、未知のコードを安全に確認しやすくなった
- レビューコメントを agent host 側に置けるようになり、レビュー指摘をエージェントに渡しやすくなった
特に Session Cost は、AI 開発の KPI 設計にかなり使いやすいです。
「AI をどれだけ使ったか」ではなく、「成果物あたり、どれだけの AI コストで、どれだけの品質に到達したか」を見る。
この見方ができると、AI コーディングは個人の便利ツールから、チームで改善できる開発プロセスに近づきます。
当社は、生成 AI コンサルティング、生成 AI を活用したシステム開発、自社プロダクト開発を通じて、こうしたエディタ側の進化を現場の開発運用に落とし込む支援を行っています。
参照元
- Visual Studio Code 1.126 Release Notes（公式） (Visual Studio Code)
- Agents window（公式ドキュメント） (Visual Studio Code)
- Workspace Trust（公式ドキュメント） (Visual Studio Code)