ハクソク

世界を動かす技術を、日本語で。

私のAIの好きな活用法はログを書くことです

2025年7月18日原文(newsletter.vickiboykis.com)

概要

  • PyCharm のFull Line Code Completion機能の特長と利便性
  • ローカル推論による 高速・安全なコード補完
  • JetBrainsによる 小型・特化型モデル の設計と圧縮手法
  • 実際の 開発・デバッグ効率化 の具体例
  • 小型モデルの将来性と 大規模汎用LLMとの住み分け

PyCharmのFull Line Code Completion体験

  • PyCharm に2023年末から標準搭載された Full Line Code Completion 機能の高い完成度
  • GoLand など他のJetBrains IDEでも利用可能な利便性
  • 開発者自身がコードの主導権を維持できる設計
  • JetBrains の長年の顧客満足度の理由となる機能追加
  • 順次処理・計算・非同期APIコール・PyTorchでのベクトル操作など多様な開発現場での活用実績

ログ出力・デバッグの効率化

  • print文デバッグ と良質なログ記述の重要性

  • f-stringによるログ記述の繰り返し作業の煩雑さ

  • 変数名やデータ構造の参照・記述ミスによる認知的負荷

  • Full Line Code Completion による自動補完でログ記述の手間を大幅削減

  • モデルが文脈を理解し、適切なログ内容を推論

    • 例: Redis URLチェックやDataFrame形状のログ自動生成

モデルのローカル推論と技術的工夫

  • モデルが 完全ローカル で動作し、 圧縮と高速化 が必須要件

  • IDE同梱可能な1GB程度のサイズに収めるため、 大規模LLMの99%を除外

  • Python専用に最適化された 小型・高速モデル

  • モデル初期はGPT-2系、後に Llama2 アーキテクチャへ移行

    • PyTorch で100Mパラメータ規模のデコーダオンリーモデルを訓練
    • 訓練データはThe Stackサブセット、45GB規模、 コメント除去 ・ import除去 によるデータクリーニング
    • Python特有のインデントを考慮した BPEトークナイザー の工夫
    • 8枚のNVIDIA A100 GPUで数日間訓練、クロスエントロピー損失で最適化

プラグイン実装・推論最適化

  • プラグイン本体は Kotlin、推論サーバは C++ でローカル実行
  • モデルを FP32→INT8量子化 し400MB→100MBへ圧縮
  • ONNX Runtime によるCPU推論、CUDA依存排除
  • サーバ側は後に llama.cpp でLlamaモデル提供に切り替え
  • ビームサーチ によるトークン生成（最大20ビーム、改行で終了）
  • キャッシュ戦略 ：コンテキストの50%を事前ロードし、既存コード編集や新規追加にも対応
  • これらの工夫により、 高速・高精度なコード補完 を実現

小型特化モデルの意義と今後

  • 大規模汎用LLM が注目される中での 小型・特化型モデル の価値
  • 単一言語・単一目的に絞ることで、 省コスト・高精度・実用性 を両立
  • 開発現場での デバッグ・ログ記述の効率化 に大きく貢献
  • 今後も 小型特化モデル のアプリケーション拡大に期待

Hackerたちの意見

面倒で時間がかかる作業を自動化してくれるのがいいね。失敗を見つけて修正するのも簡単だし、気に入ってる。ただ、唯一の心配は（多分冗長さを除いて）ログを書く瞬間が、自分の書いたことをちょっと振り返る機会になって、問題を早めに見つけることができるかもしれないってことかな。

└

そうだね、AIが実際に価値を提供してくれたのはシンプルなことだよ。ログ、ドキュメンテーション文字列、CLI関連が一番の例かな。基本的なスケッチを作って、コードに集中して、後から質の高い部分を追加してもらえるんだ。

ここで好きなのは、ローカルで動くところ。次の単語の補完にはVimのキーワード補完をよく使ってるんだけど、周りのコードを見て良い提案をしてくれるのが似たような感じだね（もちろんLLMのことはなしで）。間違うことも多いけど、全体的に時間を節約できるから、役に立ってると思う。だから、これはそれの拡張版みたいな感じかな。クラウドの「超モデル」よりも、こういうローカルで動く小さな集中モデルがたくさんある未来の方が好きだな。少なくとも、そういう選択肢があるのはいいよね。

この一見シンプルなログには、認知的負担がいくつも重なってる。まず、logger.info（それともlogging.info？コードベースによってloguruとloggerを使い分けてるから、いつも混乱しちゃう）を打つために止まらなきゃいけない。次に、括弧、f-string自体、そしてブラケット内の変数。さて、five行上のyour_variableかyour_variable_with_editsだったっけ？df.headのサブセットにアクセスするための構文は何だっけ？君が言ってるのはプログラミングって呼ばれるものだよ。これ、マジで真剣なの？forループを書くときの認知的負担はどうなるの？イテレートしてる配列に何が入ってるか、他のコードベースの部分とどう関わってるかを覚えておかなきゃいけないし、ああ、面倒なインデックスはどうするの！0から始まるのか1から始まるのか？もう無理！AI、助けて！

└

君が言ってるのはプログラミングって呼ばれるものだよ。それが君が楽しんでるプログラミングの部分なの？loggerとloggingを覚えること？俺は技術的な挑戦やデザイン、顧客の問題を解決するのが楽しかったけど、結局は自分が好きな部分に集中するのが大事だよね。

└

俺は逆に、ログラインを書くのは全然分かってる。単に面倒なだけ。AIはほぼ自分が書くであろうものを自動で補完してくれるからね。

└

コンピュータやコンピュータサイエンスの好きなところの一つは、何世代にもわたって作られた多様なツールが、人々に複雑なアイデアを実現するための力を与えてくれるところだね。どういう方法であれ、彼らはそのツールを使って、細かいことにこだわらずに大きな目標に集中できる。君はプログラミングの考え方が違う人を見ているかもしれないけど、俺はコンピュータプログラムを作ることに喜びを見出している人を見ているし、彼らは以前よりももっと多くのアイデアを実現できるようになると思う。それは祝うべきことだと思うよ。

└

そうだね、驚くべきことに、ユーザーはログ用にf-stringを使うべきじゃないんだよね。INFOレベルが設定されているかどうかに関わらず、補完されちゃうから。特に、ホットループの中で動くデバッグログを書くときには、たくさんのデータを文字列に変換することでパフォーマンスに大きな影響が出るから、これは重要だよね。でも、まあ、気にせず楽しんで。

└

ロギングコードは自分で書けるけど、ログメッセージを「きれいに」フォーマットするのが面倒なんだ。俺の経験では、AIはきれいなログメッセージを書いて、関連する変数を自動でキャッチしてくれるから、手書きの文では見逃した重要な値を含めるために二度手間になることがないんだよね。

└

そうだね、認知負荷って本当に存在するよね。プログラムの状態についての一般的な情報を記録するための適切なフォーマットを考えなくていいって、ちょっとしたことに思えるかもしれないけど、それによって他の心配事に集中できるようになるんだよね。人間の脳は、同時に大体3〜5個の意味のあるアイテムを作業記憶に保持できるっていう研究もあるし。プログラミングの流れに乗っていると、無意識のうちに作業記憶から情報を追い出したり、目の前のコードを見て再取得したりしてると思う。著者は、特定のプロジェクトのログの仕組みを思い出すために、頭の中のキャッシュから何かを追い出さなくて済むという利点を正しく観察していると思うよ（特に、10個のコードベースでそれぞれ異なるロガーを使ってるときは、なおさら厄介だよね）。

└

著者は、ログを書くのが嫌いみたいで、そのために細かく調整されたモデルを作る労力をかけてるね。「作業を自動化するためのツールを作る」って、コンピュータの主な使い方の一つだと思ってたけど、もしかしたら間違ってるかも。

└

AIブームから明らかになったことの一つは、プログラミングを生業にしている人たちが、実はプログラミングがあまり好きじゃないってことだね。どうしてこの分野に入ったのか、正直よくわからない。ギターが嫌いな人がギタリストとしてのキャリアを始めるみたいな感じかな。でも、理由はどうあれ、もうプログラミングしなくていいチャンスを得られて、結構幸せそうだね。

Hacker Newsで議論の続きを見る