目次
これまでのVibLogで実践してきた「すべてをVibe的に（生成AIに丸投げで）進めるやり方」の限界を告白します。
今シリーズの目的は、ARIAが実際の開発現場で使えるツールなのかを検証することです。 「5報の論文情報とVibe Codingをフル活用する」という戦略を掲げ、目的の速やかな達成に邁進してきました。その結果、前回までのブログでお伝えした通り、「ARIAは実践で使える可能性が高いツールである」との感触を得ましたが、明確な結論を出すにはさらなる検証が必要との見解に至りました。
今後の検証ポイントは以下の2点です。
一方、この先も「すべてをVibe的に（生成AIに丸投げで）進めるやり方」では行き詰まることが明確になりました。理由は以下の通りです。
ARIA（自律的推論AI）を駆動させるためには、ノイズのない「高純度なデータ燃料」が大量に必要です。しかし、AIの自由奔放な生成に任せていると、出力が安定せずパイプラインがすぐ崩壊してしまいます。これらを修正し、強固な基盤を作ることが今回のVibLogアップデートの主な目標です。
やるべきことは単純明快です。「生成AIが得意な処理」と「プログラミングが得意な処理」を区別し、VibLogパイプラインを再構築することです。
現時点での生成AIの弱点は以下の通りです。
そこで本アップデートでは、以下の4点を実施しました。
結果として、「人間が読めば数時間かかる半導体パッケージング論文の因果関係抽出を、1時間・わずか15円のAPIコストで900ノードのグラフに変換する」という驚異的な成果を叩き出すことに成功しました。
次章からは、新生VibLogのカギとなる「ガードレール」設計の裏話を中心にお伝えします。
Pythonで処理フロー全体を規定したことにより、生成AIが記憶しておくべき情報量を大きく圧縮できました。これだけでも生成AIが「手抜きやおさぼり」をしにくい土壌に変わっています。
しかし、「論文からナレッジ（PSP）を抽出する」「抽出したナレッジを正規化する」といった作業を高精度で実施するためには、依然として大量の情報を保持しなくてはいけません。論文の内容によって、文章の長さ、複雑さはまちまちです。高難易度の論文処理を完全にAI任せにすると、確実に巧妙な手抜きを行います。
そこで重要な役割を果たすのが、AIに強力な行動制限を課す「ガードレール」であり、その設計こそが新生VibLog成功のカギを握っています。
これまで通り、Roo Code等のエージェントを使い、可能な限りVibe的に（対話を通じて）作業を行います。従来との違いは、AIにすべてを「良しなにやっておいて」と頼むのではなく、人間（アーキテクト）が明確な制約（ガードレール）を設計し、それをコーディングやMarkdown形式に落とし込む「実装作業」をAIに担当させる点です。
Markdownによる規制文（プロンプト）だけにすべてを委ねることはせず、Pythonコード中に強力な検閲機構を組み込み、かつ違反発生時のプロトコルを定義しておく。このような「２層ガードレール構造」をとりいれることこそが、質の高いKGを安定して自動生成させる最大のコツです。
また、今回の改修により、将来的に利用する生成AIモデルが変わっても問題が起きないシステム設計になったことも重要です。現在の従量課金制のVertex AIから、軽量なオープンモデルのローカルLLMに乗り換えてコスト削減したり、GoogleだけではなくOpenAIやAnthropicの最新モデルに切り替えて更なる精度向上を目指したりと、柔軟な拡張が可能になっています。
ここがエンジニアや研究者の皆様に最も共感していただけるであろう「現場のリアル」です。きれいに自動化できたように見えて、実は裏では様々なトラブルが起こりました。これらのトラブルにより、改修作業は当初の計画よりもかなりの時間がかかりました。読者の皆さんが同じことを経験したときに役に立つよう、包み隠さず内容をお伝えします。
テスト用の文章を使った「ガードレール設計」が完了し、いよいよ複数の論文を流し込んで本格抽出開始、というところで予期せぬ問題が発生しました。
導入したガードレールに関わる「Pydanticの型違反」や「チャンク分割の不具合」を疑って詳しく調査したところ、意外にも「私が危険コンテンツを処理している」というシステムの誤検知が原因でした。
本プロジェクトでは半導体後工程関係の論文を扱っているため、まさか「危険コンテンツ」と判定されるとは夢にも思っていませんでした。実際は、「応力（Stress）」や「破壊（Failure）」といったMI（マテリアルズ・インフォマティクス）特有の学術用語が、APIのセーフティフィルターに「暴力的コンテンツ」として誤検知され、出力が突然物理的に遮断される怪奇現象を引き起こしていたのです。
解決策として選んだのは、SDKの明示的なEnumクラス（BLOCK_NONE）を使って安全装置を完全にオフにするというハックです。一般に広く公開するアプリを開発しているのであれば、システムの安全フィルターを無効化しない方が良いのは言うまでもありませんが、今回はクローズドな個人のプロジェクトということでこの手段を採用しました。
以前もお話ししましたが、今回は個人のプロジェクトであるため「コスパ」を最重要事項として定めています。プロジェクトを開始する前の今年２月、DeepResearchの調査結果をもとにコスパ最強の手段を選択しました。それが、「Google AI Studioの無料特典枠を利用する」という方法でした。
しかし、無料枠のつもりでGemini APIを利用していたら、Googleから突然課金を知らせる連絡メールが届いたのです。Geminiに原因調査を依頼しても「無料枠が使えます」との回答しか返しません。久々に自力で調査した結果、私が当てにしていたGemini APIの無料特典枠は、なんと３月をもって対象外になっていたことが発覚しました。同時に、代替となる「Vertex AIの無料特典」も発見することができ、ほっと一息です。
これまで使っていた「Gemini AI Studio」が主に個人が実証実験的に使うことを想定したものであるのに対し、「Vertex AI」は商用サービスとして生成AIをエンタープライズのアプリに組み込む際に利用することを想定されたものです。コスパ最優先の私としては緊急オペを実施し、Vertex AI APIへの切り替えを完了させました。
今後は無料特典を使い切る勢いで論文からのKG抽出を進めたいと思います。とはいえ、すでに課金されたお金は戻ってきません。生成AI関連のサービスはまさに「日替わりメニュー」です。皆さんも私と同じ失敗をしないよう、最新情報には常に目を光らせておいてください。
最新の生成AIは、数十万文字を一度に読み込める「ロングコンテキスト」を大きなうたい文句にしています。当初はそれを信じて、論文1報を丸ごと一度に処理させようと試みました。しかし、実際には『読める』ことと『細部まで理解して抽出する』ことは全くの別物でした。
情報量が多すぎると、AIは露骨に抽出をサボり（Lost in the Middle現象）、結果がスカスカになったのです。結局、人間が本を読むように、テキストを意味のある段落ごとに分割（チャンク分割）して少しずつ読ませるという、非常に泥臭い『再帰的チャンク分割』の実装が必要でした。
ロングコンテキストモデルだからといって、PDFを丸投げすれば魔法のように構造化されるわけではない、という良い教訓になりました。
新生VibLogは、これまで通りVibe Codingの良さは活かしつつ、「アーキテクトとしての人間がガードレールを引き、実装を生成AIに任せる」という新しい形で作業を行いました。出来上がったワークフローは、Pythonによる厳格な作業規定と、生成AIが得意な応用作業のコラボレーションにより、極めて高いレジリエンス（回復力）を備えたものに進化しています。
次回は、新生VibLogで精製された高純度燃料（JSON-LD）の中身を公開する予定です。「5報」という最小グラフからどのように進化したのかをNeo4j等で可視化し、わかりやすくお伝えしようと思います。そのうえで、その高純度燃料をARIAにどう喰わせて、どのように結果を得るのかという実践編に入っていきます。お楽しみに！
※本記事に記載されている会社名・製品名・サービス名は、 各社の商標または登録商標です。