GitHub Copilotが個人ユーザー(Free／Pro／Pro+)のインタラクションデータを、デフォルトでAIモデルの学習に活用する方針へと転換するようです。 この変更は入力したコードスニペットやコメント、採用した提案、カーソル周辺の文脈など、開発者が実際にCopilotとやり取りするリアルな開発行動をモデル改善に反映させることを目的としています。 これにより、Copilotはより文脈を理解し、精度の高い提案を行う実務レベルのAIアシスタントへ進化することが期待されています。 その一方でデフォルトが学習オンである点や、プライベートリポジトリ使用中のデータが学習対象になり得る点など、開発者コミュニティでは議論盛り上がっていたので、整理し考察したいと思います。 参考：Updates to GitHub Copilot interaction data usage policy 問題視され

これはバイブコーディングが出てきた時に言われていたことですね。コードが早く書けるからといって誰もがすぐにできるわけではない。 しかし、これではAIの次の技術が出てきた時にも同様の議論がされそうです。 そのため、もう一段深い思考が必要だと考えます。 自分で試して限界を知ることが大事ということではなく、そもそもお金が何に対して支払われているかを考える必要があります。 つい最近書いた記事ですが、 米に価値があるのではなく、米の品質管理に対しての対価であるという考え方をすると、バイブコーディングないし全てを包括して理解可能です。 つまり、金額が高いものは、とんでもなくうまいわけではないということです。 品質が担保されていることにお金を支払っているのです。 そのため、逆に言えば安いから粗悪でもありません。 三つ買って一番いいものを残す方式であれば、安いものでもある一定の品質ものを手に入れられるわけで

数字だけ見れば9Bが圧倒的に速いで終わる。だがこのテーブルには、スペック表からは絶対に読み取れない情報が埋まっている。 発見1: 同じ7.5GB VRAMなのに速度が10倍違う VRAM使用量を見てほしい。7.1GB、7.7GB、7.6GB。ほぼ横並びだ。スペック表的には3モデルとも8GBに収まる、OKで話が終わる。 ところが速度は33 t/s、3.5 t/s、8.6 t/s。最大10倍の差。VRAM使用量からは速度差を予測できない。 差の正体はGPU利用率にある。 9B (91%): 全層がGPU上にある。GPUの演算ユニットをほぼフルに使い切っている。 27B dense (60%): 58層中24層しかGPUに載っていない。残り34層はCPUで処理。GPUは自分の分を処理し終わってもCPUの処理完了を待っている。GPU利用率60%の意味は、40%の時間GPUが遊んでいるということだ。

最近、Claude CodeやCopilot Agentを触り始めたんだけど、正直な感想として「素のAgent、思ったより微妙じゃない？」って思ったんですよね。 チャットはできる。コードも生成してくれる。でも、なんか…プロダクションレベルじゃない。 例えばこんな感じ： コードは書けるけど、設計パターンがめちゃくちゃ 質問には答えてくれるけど、実務のベストプラクティスを知らない UIは生成できるけど、どう見てもデザイン素人が作った感じ 要するに、スマホを買ったけどアプリを何もインストールしてない状態。OSはあるのに、使い道がない。 Skillsって何？ Skillsはプラグインとはちょっと違います。Agentに業界のベストプラクティス、実プロジェクトの経験値、エンジニアリングの制約ルール、構造化された思考フレームワークを注入するものです。 つまり、「Agent の地頭」を底上げする仕組みです

Claude Codeを使っていると、こうすればもっと便利になりそうという気づきが積み重なります。ただ、そのたびに作業を止めて設定ファイルを開くのは気が乗りません。 「気づいたら設定が整っている」という状態が欲しくて、試行錯誤しました。 /insights だけでは物足りなかった Claude Codeには/insightsというビルトインコマンドがあります。過去のセッション履歴を分析して使い方のパターンや改善ポイントをレポートしてくれる機能です。有用なのですが、使っていて2点が気になりました。 カスタマイズできない: 提案内容や検出ロジックを自分で調整できないため、自分のワークフローに合った提案が得られません。（それが良さでもありますが。） 面倒: コマンドを実行し、それをブラウザで毎回読む必要があります。私が欲しいのはレポートではなく、気づいたら設定が整っている状態です。 そこで、/i