AIBR プレミアム
拓海先生、部下から『AIにコード学習させて開発支援するべきだ』と言われまして、ただ語彙の扱いで苦戦する論文があると聞きました。何を気にすればよいのでしょうか。
素晴らしい着眼点ですね！要点はシンプルです。ソースコードに何を『単語』として与えるかで、学習の可否や精度が大きく変わるんですよ。大丈夫、一緒に整理していけるんです。
『単語』と言われると、日本語の文章と同じように考えてよいのですか。うちの現場だと変数名がバラバラで統一感がなく、学習がうまくいくか不安です。
良い疑問です。まずは三点で考えればわかりやすいですよ。1) 何を語彙に入れるか、2) まったく使われない語をどう扱うか、3) 複合語を分割するかどうか、です。この整理が設計の出発点なんです。
なるほど。で、現場のコードはプロジェクトごとに違うワケだから、全部を学習させると語彙が膨らみすぎて学習できなくなるという話も聞きましたが、それは本当ですか。
その通りです。Neural Language Model（NLM：ニューラル言語モデル）のような手法は語彙サイズに敏感で、語が増えすぎると学習が事実上できなくなることがあります。だから語彙設計が極めて重要になるんです。
これって要するに、語彙をどう切り詰めるかでAIが使えるかどうかが決まるということですか。実務でやるならコストも気になります。
要するにその通りです！投資対効果の観点でも語彙設計は重要で、賢く選べば少ないデータと計算で高い精度が出せるんです。実務で使える観点を三点だけ挙げると、まず語彙のフィルタ、次に複合語の分割、最後に学習対象の絞り込みです。
具体的な方法はありますか。分割というのは、例えばcamelCaseを小分けにするようなことを指しますか。
その通りです。Identifier splitting（識別子分割）やsubword tokenization（サブワード分割）を使うと、膨大な固有名詞を小さな単位にして共通性を作れるんです。身近な例で言えば、長い商品コードを桁ごとや接頭辞で区切るイメージです。
それなら現場の命名規則がバラバラでも、共通部分を学べそうですね。導入時のハードルはどこにありますか。
導入のハードルは主に二点です。1) 前処理ルールの設計に時間がかかる、2) 語彙フィルタを誤ると重要な専門用語を消してしまう、です。とはいえ、小さく試してルールを改善するやり方でリスクを抑えられるんです。
小さく試して改善、ですね。要点を三つにまとめてもらえますか。会議で短く説明する必要があるもので。
もちろんです。短く三点です。第一に、語彙を設計して『減らせる無駄』を減らすこと、第二に、複合語は分割して共通パターンを抽出すること、第三に、小規模データで実験してルールを改善すること。これで提案できますよ。
分かりました。では試作はまずどの範囲のプロジェクトでやるべきでしょうか。社内だけで完結させた方がいいですか。
まずは自社の代表的なプロジェクト数本で試すのが現実的です。環境が違う外部プロジェクトを混ぜると語彙の多様性が増えすぎますから、社内標準に近いコードを使いルールを固めるのが効率的なんです。
最後に、私が会議で言える短い一言をください。技術屋ではない私でも言える言葉が欲しいです。
いいですね。会議ではこう言ってください。「まずは社内コード数本で語彙設計を試し、現場ルール化してから拡張します」。これだけで投資判断がしやすくなりますよ。
承知しました。自分の言葉でまとめると、語彙を賢く整理してから学習させることで、無駄なコストを抑えながら実用性のあるAIを早く試せる、ということで正しいですか。
まさにその通りですよ。大丈夫、一緒にやれば必ずできますよ。
