Qiitaに100週連続投稿したので振り返る

Last updated at 2026-08-25Posted at 2026-08-25

はじめに

2年ほど前から週1でQiitaへ投稿しており、本記事で100週連続投稿となりました。

区切りが良いので、前回の振り返り以降に公開した60本強を振り返ります。

開発環境整備

VS Code使いこなし

AIコーディングがどんどん実用的になっている時期（2025年4月以降）に、設定をいろいろ試行錯誤していました。
VS Codeのエージェント機能を試用したり、AIコーディング向けのPythonリポジトリテンプレートを作ったりしました。また、Cursor Agent導入前後の活動を比較しました。ちなみに、プルリクエスト数は2か月あたり13件から42件へ増えたと当時書いていましたが、今はおそらく2か月で100〜200件ほどのプルリクエストを作っているので、AIの大きな進歩を感じます。

またAIコーディングそのものではないですが、当時リリースされたOpenAI Agents SDKの使い方を試しました。

Copilot CLI

2026年になると、AIの性能向上に伴って、開発環境の中心がVS CodeなどのIDEからCLIへ徐々に移行してきました。
当時はCopilot CLIが圧倒的なコスパを誇っていたので、Copilot CLIの使いこなしをいろいろ検討していました。

その他

開発を進める中で詰まったことや方針で定まったことを、メモする感覚で、整理しました。
2つめの記事は今でもときどきリアクションがつきます。

RAG・エージェント関連の技術調査

RAG

RAGのときによくやる実装をライブラリの具体的な使い方を含めて記事化しました。

LLMの性能検証として、LLMの正確コピー（exact-copying）性能を検証したり、検索順位からhit rateやrecallなどを計算する処理したうえで、LLMが検索結果の妥当性を判定する能力を、MIRACLデータセットを用いて定量評価しました。RAGASの内部プロンプトを詳細に読んで理解したり、NVIDIA Metricsのcontext relevanceという指標を試したりもしました。

エージェント技術の論文読み

rStar2-Agentの論文やマルチエージェントが効果を発揮する条件を調べた論文も読みました。後者の論文は、エージェント構成によるベンチマーク精度の違いを、なるべく統制された条件で検証していて面白かったです。

空耳自動生成

趣味でやっている空耳自動生成関連の研究開発です。

「聞こえた音をそのまま文字にする」ための試行錯誤

通常の音声認識は、言語モデルによってもっともらしい文章に補正されます。空耳や替え歌の分析では、その補正よりも「実際にどのように聞こえるか」を取り出したいので、カナや音素を直接認識する方法を試しました。特に洋楽歌詞のカナ化を目指していましたが、まだまだハードルは高い状況です。

カナASRモデルを用いる方法と、漢字カナ混じり認識モデルを後処理でカナ化する方法を、無意味カナ文字列に対して、精度比較しました。無意味かな文字列では漢字カナ混じりを後処理でカナ化するほうが精度がよさそうでした。

一方で、本命である洋楽歌唱音源のカナ認識はいずれの方法でも、かなり難しかったです。強いて言えば、音素ASRをルールベースでカナに変換する方法が、耳で聞いた印象に近かったです。

カナ化はせずとも音韻的な類似度が取れたらよいのでふりがなWhisperの中間表現がどの程度、音韻特徴を反映しているか眺めてみましたが、意味や文脈の影響も大きく、実用レベルではなさそうでした。

カナ化ではないですが、テキストから得た複数の読み候補をCTC forced alignmentの尤度で比較し、歌唱音源に合う読みを選ぶ方法も実装しました。「明日」を「アシタ」と読むか「アス」と読むかのように、テキストだけでは決められない読みを音源から補えるようになりました。

意味と音の両方を扱いたい

「〇〇で歌ってみた」の替え歌生成では、意味はほぼ不要で、音韻の類似度のみが重要ですが、一般的なラップや替え歌では意味（文脈）と音韻の両方をバランスよく重視する必要があります。そこで、編集距離が近い単語の検索を高速化し、意味と音韻の両方を考慮した単語検索を試しました。短い単語では役立つ場合がありましたが、長い単語では音韻条件だけで候補が絞られ、意味の近い語が残りにくいという課題がありました。

音韻条件を加えたマスク単語予測や、言語モデルと母音フィルタを用いた韻踏み文生成、かな文字列で学習されたLLMによる韻生成も試しましたが、自然な文章を安定して作るところまではいきませんでした。

LLMは音韻を理解しているのか

LLMの音韻理解能力を、自作の音韻検索ベンチマークを用いて、詳細に評価しました。LLMの音韻能力が高ければ空耳生成に活用できると思われるためです。

素朴な設定では、LLMの音韻検索能力は簡単なルールベース手法に劣りますが、プロンプトと推論の有無などの軸でいろいろ比較したところ、音韻の比較手順を明示した推論モデルが、それまで最良だったルールベースのRecall@10を上回りました。

ここから、「LLMは本当に音韻を理解したのか、それとも文字列操作をしているだけなのか」が気になり、検証を続けました。

特に編集距離の検証では、複数文字が1トークンになる場合に誤りやすく、文字間をスペースで区切ると改善しました。一方、音韻検索全体では単純にスペースを入れるだけでは改善せず、個別能力の改善が最終タスクの改善にそのままつながるとは限らないことも分かりました。

研究の位置づけを整理するため、Phun-Bench、PhonologyBench、YOMI-Bench、P-CoTの論文も読みました。

Webアプリ改善

「〇〇で歌ってみた」替え歌作詞支援システム「Soramimic」でも使っている音韻類似度算出ロジックのパラメータを、操作結果が感覚と合うように調整しました。また、英語をカナ化するときに辞書外の単語にも対応するため、機械学習ベースの英語―カタカナ変換ライブラリも比較し、よさそうなものをアプリに取り込みました。

架空人物の生成と顔の多様性

空耳替え歌動画などで使える、権利面で扱いやすい人物素材を作るため、LLMで架空の科学者の名前、経歴、肖像画を生成するパイプラインを作りました。

生成結果を並べると、時代や地域が共通のグループ内で顔の多様性が出にくい（みんな同じ顔に見える）問題がありました。そこで、顔埋め込みとVLMで多様性を評価する指標を検討し、その指標を用いて、顔生成の多様性を高める試行錯誤をしました。

を試しました。指標的にはローカルモデルへの特徴注入が一番良かったですが、定性的にはどの手法も一長一短という感じでした。

ネタ

人は見た目も話し方も9割であることが長らく気になっていたので、「aはbがc割」系の書籍タイトルを国会図書館のデータから集めて合計しました。人は全部で54割でした。

おわりに

最近はVSCodeをほぼ使っていないので、1年半前はVSCodeの設定で試行錯誤をしていたのだなあと、LLM界隈の進歩の速さを感じました。
これからもゆるく記事は書き続けていければと思います。