AIエージェントの記録から不具合の原因をOSS「Langfuse」はどう追うのか

「エージェントの返事が昨日と急に変わったのに、理由を説明できない」「記録は残しているつもりだが、何を残してよいのか、誰が見てよいのかを決めていない」——AIエージェントを業務で動かし始めた企業の、情報システム担当やセキュリティ担当の方から届く声です。こうした悩みは、記録を取る道具を一つ入れれば片づくように見えます。しかし本当の課題は道具の数ではありません。記録に何を残し、誰が見て、変わったときにどう判断するかを、先に決めているかどうかが分かれ目です。この記事では、AIエージェントの動きを記録し、出力の変化や失敗の原因を追えるようにするOSS「Langfuse」を取り上げ、記録の仕組みと、ライセンス表記や導入時に動く処理、公開されている勧告といった注意点を、一次情報に基づいて整理します。導入や設定の手順は扱いません。

Langfuseとは何か。2026年10月時点で確かめられる事実

Langfuseは、GitHubで公開されているOSSです。READMEでは「オープンソースのAI（大規模言語モデル）向けの基盤」と説明され、チームでAIアプリを開発し、監視し、評価し、不具合の原因を調べるために使うとされています。主な機能として、AIの動きを段階ごとに記録する仕組み、プロンプトの管理、評価、試験用の問題集、試行用の画面、外部から操作するための仕組みが挙げられています。

配布と運営の状況を確かめておきます。リポジトリは2023年5月18日に作られ、2026年10月16日時点でスターは35,887、フォーク（派生）は3,996、最後の更新は同じ日でした。公開しているのは組織のアカウントで、2023年5月25日に作られ、ほかに27のリポジトリを公開しています。READMEには、2026年1月からClickHouseの一部になったと書かれています。運営の主体が変わっている点は、長く使う道具を選ぶときに確かめておきたい材料です。

使い方には二つの形があります。自分の環境に置いて動かす形と、事業者が運用しているクラウドを使う形です。事業者の説明では、クラウドのデータの置き場所は米国・欧州・日本から選べ、医療情報向けの区域も用意されているとされています。自社に置く形では、外部に接続せずに運用することもできるとされています。どこに会話が残るかは、後の章で扱う守りの前提になります。

日本向けの情報も用意されています。READMEには日本語の版があり、国内でも名前を見かける道具です。事業者の説明では、記録の保管場所として日本を選べるとされています。社内で説明するときに、日本語の資料から始められるのは実務上の利点です。

なぜ今、AIエージェントの記録が必要なのか

エージェントは、質問に答えるだけでなく、道具を呼び出し、社内のシステムや外部のサービスに触れます。同じ入力でも、モデルの更新やプロンプトの変更、呼び出す道具の説明の変化といった理由で結果が変わります。昨日まで正しく動いていた処理が、今日は別の答えを返すことが起こりうるのは、このためです。

従来のサーバの監視は、機械が止まっていないか、エラーが出ていないかを見るものでした。しかしAIの場合、エラーを出さずに「もっともらしいが違う答え」が返ることがあります。原因を追うには、どんな入力に対して、どの段階で、何が返ったかという並びを残しておく必要があります。

台帳のメモにある「昨日まで動いてたのに、急に出来なくなった」という相談は、まさにこの型の困りごとです。記録があれば、動いていたときと、動かなくなったときの記録を並べ、どこで差が出たかを人が確かめられます。逆に記録がなければ、思い出と推測だけが残ります。

何を記録するのか。会話・道具の呼び出し・時間と費用

READMEによると、Langfuseの中心は記録の仕組みです。アプリに組み込むと、モデルの呼び出しだけでなく、検索、埋め込み、エージェントの操作といった関連する処理も取り込み、一つの処理を木のような親子の関係で残します。どの段階で時間がかかったか、どこで失敗したかを、並べたまま見られます。

記録には、各段階の入力と出力、かかった時間、使った語数の目安と費用が含まれます。利用者ごとのまとまりで見ることもでき、READMEは複雑な記録と利用者の流れを調べる用途を挙げています。費用の増え方は、異常に気づく手がかりとしても使えます。

ただし、記録する範囲が自動で決まるわけではありません。主要な開発部品向けには、組み込むだけで記録が取れる用意があるとされますが、どの処理をどの粒度で残すかは設計しだいです。残す範囲を広げるほど原因は追いやすいが、機密も一緒に入るため、この設計は技術だけでなく守りの問題でもあります。

「昨日まで動いていたのに急に動かない」原因を記録からどう探すのか

実際の原因追跡は、次のような順で進みます。まず、うまくいったときと同じ種類の処理を探し、失敗した記録と並べます。次に、どの段階で差が出たかを見ます。入力が変わったのか、道具の呼び出しが変わったのか、モデルの応答だけが変わったのかで、疑う先が変わります。

続いて、変更の履歴と時刻を突き合わせます。モデルの切り替え、プロンプトの修正、道具の定義の更新、外部サービスの仕様変更。これらが記録の変化と重なっていれば、原因の候補はぐっと絞られます。記録は事実の並びであって、原因の説明そのものではない点は、忘れないようにしたいところです。

ここでAIの使いどころがあります。大量の記録から似た失敗を集めたり、変化のあった箇所を指摘させたりするのは、人の目を助けます。ただし、原因の断定は人が行います。AIには候補を挙げさせ、根拠にした記録を添えさせて、人が確かめる。この順番を決めておくと、もっともらしい推測に引きずられにくくなります。

記録を評価に使う。採点の仕組みと人の確認

Langfuseは、記録を残すだけでなく、出力を評価する機能を持ちます。READMEによると、モデルに判定させる方法、プログラムで判定する方法、利用者からの反応を集める方法、人手で印を付ける方法、独自の評価の流れを組む方法が挙げられています。

評価は、試験用の問題集と組み合わせて使います。あらかじめ用意した問いと正解の見本に対して、変更の前後の結果を比べることで、改善したのか、それとも悪くなったのかを、公開の前に確かめられます。

ただし、判定の基準は人が決めます。何をもって正解とするか、どのくらいの誤りなら許すかは、業務の都合と法令の要請で変わります。AIに採点させる場合も、なぜその点数にしたのかの根拠を書かせるようにしておけば、あとから人が確かめられます。評価は「測った範囲」しか示さない、という限界も押さえておきます。

プロンプトの版管理と、変更の履歴を追う仕組み

エージェントの振る舞いは、プロンプト（AIに最初に与える指示）で大きく変わります。READMEによると、Langfuseではプロンプトを一か所で管理し、版を記録し、チームで共同して改善できるとされています。サーバ側とクライアント側の強いキャッシュにより、改善してもアプリの応答が遅くなりにくいと説明されています。

記録と管理がつながっていると、ある結果が「どの版のプロンプトによるものか」を後からたどれます。試行用の画面に記録から直接移り、指示を変えて試せる仕組みも挙げられています。

守りの観点では、いつ、誰が、何を変えたかが残ること自体が価値になります。障害の対応でも、社内の統制でも、変更の履歴は説明の材料になります。ただし、変更の履歴も記録の一部です。記録の全体を誰が読めるのかは、あわせて決めておく必要があります。

導入の形：自社に置くか、クラウドを使うか

導入の形は大きく二つです。自分の環境に置く形では、リポジトリに同梱された構成ファイルを使って、コンテナを組み合わせて動かす方法や、仮想マシン、クラスタで動かす方法が示されています。事業者の説明では、外部に接続しない使い方もできるとされています。

もう一つは、事業者が運用するクラウドを使う形です。運用の手間は減りますが、記録が自社の外に出ます。事業者は、記録の保管場所を米国・欧州・日本から選べること、機密を伏せる仕組み、保存期間、削除の機能を用意していると説明しています。ただし、これらは使う側が設定して初めて働くもので、既定のまま全部が伏せられるわけではありません。

判断の分かれ目は、記録に出てくる情報を外に置けるかどうかです。顧客の個人情報や取引の内容が入るなら、自社に置く形を選ぶか、少なくとも伏せる設定と保存期間を先に決める必要があります。どちらを選ぶかは、道具の性能ではなく、自社の情報をどこに置けるかで決めるのが順序です。

表で比べる：記録を残す手段としての違い

記録を残す手段は、Langfuseだけではありません。自前で記録を組み込む方法、サーバやアプリの一般的な監視の道具を使う方法、AI向けの記録の道具を使う方法があります。下の表は、一次情報と一般的な性質をもとに整理したものです。個々の道具の作りによって変わります。

見る点	自前の記録	一般的な監視の道具	Langfuseの場合
会話の入力と出力	実装しだい	対象外のことが多い	記録の中心として扱う
道具の呼び出しの親子関係	実装しだい	苦手とされる	親子の関係で残す
時間と費用の把握	実装しだい	時間は見られる	段階ごとに見られる
プロンプトの版管理	なし	なし	あり
出力の評価の実施	なし	なし	評価の機能がある
保存場所と保存期間	自由に決められる	自由に決められる	自社に置く形なら自由
導入の負担	大きい	中くらい	置く形では中くらい

表のとおり、AI向けの記録の道具は、会話と道具の呼び出しを前提に組み立てられている点が特徴です。一方で、一般的な監視の道具が不要になるわけではありません。サーバの異常や通信の遮断など、AIの外側の異常は従来の道具の担当です。役割を分けて組み合わせるのが現実的です。

もう一つ、表で見落としやすいのが費用です。記録を長く残すほど保管の費用が増え、記録を取る処理そのものがアプリの負担になることもあります。何をどの粒度で、いつまで残すかを決めることは、原因の追いやすさと費用の両方に効きます。

安全性の評価：注意付きとした根拠

このラインでは、紹介するOSSを公開情報だけで精査しています。クローンやインストール、実行はしません。Langfuseの判定は「注意付き」です。この判定は「危険」という意味ではなく、注意付きの条件に当てはまる項目がある、という意味です。

根拠にした事実は三つです。一つ目、ライセンスの表記を自動で判別できず、リポジトリのライセンス欄が「判別不能」と表示されること。二つ目、開発用の構成ファイルに、インストール時に自動で動く処理が書かれていたこと。三つ目、公開されているセキュリティ勧告が4件（中3件・低1件）あったことです。詳しくは次の章で扱います。

一方で、作者は匿名ではなく組織のアカウントで、作られてから3年以上が経ち、スターの伸びは1日あたり約29件でした。不自然な水増しの兆候は見られません。問題が見つからないことと、安全であることは別です。ここでの精査は公開情報の範囲に限られ、コードの中身を検証したものではありません。

ライセンス表記が判別できない理由

一つ目の根拠を詳しく見ます。リポジトリのライセンス欄は、Langfuseの場合「判別不能」と表示されます。これは「ライセンスが無い」という意味ではなく、自動判定が分類できなかったという意味です。

リポジトリのライセンス文書を読むと、内容は明確です。2023年から2026年のClickHouse, Inc.の著作権表示のあとに、三つの区分が並んでいます。すべての内容に当てはまるのは、MITライセンスです。ただし例外として、eeという名前のフォルダなど一部の内容は、その中の別のライセンス文書に従うと書かれています。READMEも「このリポジトリはMITライセンス、eeフォルダを除く」と明記しています。

つまり、判別できないのは複数の条件が一つの文書に混ざっているためと考えられます（推測）。実務では、使う範囲がeeのフォルダに入るかどうかで、条件が変わる点が重要です。事業者が提供する有償の機能は、この別ライセンスの範囲にあるとされます。導入の前に、使う範囲がどちらの条件に入るかを、法務と確認しておく価値があります。

インストール時に自動で動く処理と、公開されている勧告4件

二つ目の根拠です。開発に使う構成ファイルには、取り込み時に自動で動く処理が三つ書かれていました。一つは、決められたパッケージ管理の道具以外では処理を止めるもの。一つは、同梱の補助スクリプトがあればシェルスクリプトとして実行するもの。一つは、変更を記録する前に自動の整形を走らせる準備です。

自動で何かが動くこと自体は、開発の現場では珍しくありません。気をつけたいのは、何が自動で動くのかを知らないまま取り込むことです。特に、同梱のスクリプトを実行する処理は、中身を確かめずに走らせると、意図しない変更や外部との通信につながりえます。業務で使うなら、配布されたイメージやパッケージを検証してから使う工程を決めておきます。

三つ目の根拠は、公開されている勧告4件です。いずれも公開の状態で、深刻さは中が3件、低が1件です。内容は、役割が限定された利用者が保管されたモデル事業者の鍵を取り出せた問題（CVE-2026-41487）、認証されていないSlack連携の設定で任意のプロジェクトに結び付けられた問題（CVE-2026-24055）、シングルサインオンを通じたアカウント乗っ取りの問題（CVE-2025-65107）、組織をまたいでメンバーや招待の一覧を取得できた問題（CVE-2025-64504）です。

4件のうち3件が、権限やアクセスの制御に関するものです。記録の基盤そのものが、攻撃の対象になることを示しています。なお、それぞれの修正版がどの版で出たかは、今回の精査では確認できませんでした。セキュリティの方針の文書は、常に最新の版を使うことを強く勧めています。

記録に個人情報や機密が混じるリスク

記録の道具を入れるとき、最も見落とされやすいのがこの点です。記録には、入力した文章と出力された文章がそのまま入りえます。入力に顧客の氏名や連絡先、出力に社内文書の要約、道具の呼び出しに認証情報や接続先が含まれていれば、それらも記録に残ります。

事業者は、機密を伏せる仕組みや、保存期間、削除の機能を用意していると説明しています。ただしそれらは、使う側が指定して初めて働きます。何を残さないかは、道具ではなく自社が決める必要があります。

記録に入りうる情報	そのまま残すと困ること	先に決めておくこと
顧客の氏名・連絡先	目的外の利用と漏えいの危険	伏せる規則と、扱う根拠
出力に含まれる社内文書	権限のない社員が見られる	閲覧できる役割の範囲
モデル事業者の鍵	漏れると外部から使われる	記録に残さない設定
道具の呼び出しの内容	接続先や内部の作りが分かる	残す段階と粒度
やり取りの全文	保存が増え続け、事故の影響が広がる	保存期間と削除の時期

表のとおり、記録は「あれば便利な資料」ではなく、新しい機密の保管場所になります。個人情報が入るなら、その記録も個人データとして扱う必要があります。何のために残すのかを決め、その目的の外では使わない。目的を決めずに全部を残す運用は、いずれ事故の規模を大きくします。

設計を決めるときは、記録する側の都合と、記録される側の立場の両方を思い浮かべます。顧客とのやり取りを残すなら、残す目的を説明できる状態にしておきます。社員の操作を残すなら、評価ではなく原因の追跡と品質の改善のために使う、という目的を先に共有しておきます。目的の共有がないまま記録だけが増えると、現場は記録を隠すようになります。

悪用されうるリスク

Langfuseは守りのための道具で、攻撃に使う道具ではありません。それでも、置き方しだいで生まれうる危険はあります。最も大きいのは、記録の置き場が「宝物の山」になることです。会話の記録には、社内の事情、顧客の情報、ときには鍵が入ります。ここが読まれれば、攻撃する側は社内の作りを推測でき、正規の利用者になりすます手がかりも得られます。

次に挙げるのは推測ですが、勧告4件のうち3件が権限やアクセス制御に関するものだったことは、無視できません。記録を見る権限の設計が甘ければ、道具そのものの弱点より先に、記録の中身が漏れると考えられます。

社内からの持ち出しも同じです。記録の画面を全社に開くと、権限のない社員が機密に触れます。書き出しの機能を使えば、記録を外部に持ち出せます。見られる人を役割で絞り、書き出しを記録に残すといった基本の対策が要ります。なお、この道具が実際に悪用された事例は、2026年10月16日時点の一次情報からは確認できませんでした。

導入を検討するときに確かめること

Langfuseに限らず、記録の道具を検討するときは、機能の多さより先に確かめたい点があります。下の手順は、動かす前の段階で、資料と社内の取り決めで確かめられることに絞っています。

要は、道具を入れる前に、記録の扱いを文書で決めておくことです。記録は入れた瞬間から増え始めます。あとから「この記録は誰が見てよいのか」を決めるのは、はるかに難しくなります。

導入した後も、記録の設計は見直します。記録の量、かかる費用、現場からの問い合わせの内容を定期的に確かめ、残す範囲を狭めたり広げたりします。設計は一度決めて終わりではなく、運用しながら調整するものと考えておくと、現場の負担と守りの水準を両立しやすくなります。

企業が取るべき対策

一つ目は、記録の設計を文書で決めることです。何を残し、何を伏せ、いつ消し、誰が見るか。この四つを決めていない記録は、資産ではなく負債になる可能性があります。個人情報が入るなら、目的と保管の期間もあわせて決めます。

二つ目は、記録の基盤を守る対象として扱うことです。記録の道具は、社内の機密が集まる場所になります。認証、権限、通信の分離、更新の適用を、業務システムと同じ水準で扱います。三つ目は、勧告と更新を追う体制です。今回の4件のように、権限の設計に関わる問題は、記録の中身に直結します。利用中の版と、公開されている勧告を定期的に突き合わせる担当を決めます。

四つ目は、評価を人の判断に組み込むことです。AIによる採点は、大量の出力を短時間でふるい分けるのに役立ちます。ただし、それをそのまま成果の指標や人事の判断に使うと、採点の基準の偏りがそのまま組織の判断になります。五つ目は、調達の段階での確認です。運営の主体、データの置き場所、保存と削除の条件、障害時の連絡先を、導入の前に文書で確かめます。

AIに任せる範囲と、人が決める範囲

Langfuseは、評価にAIのモデルを使う方法を用意しています。大量の記録をふるい分け、怪しいものを絞る用途では、人の目を大きく助けます。ただし、良し悪しの基準をAIに任せてはいけないところです。

同じことは、原因の分析にも当てはまります。AIに記録を読ませて原因の候補を挙げさせるのは有効ですが、候補に基づいて設定を変え、本番に出すかどうかは人が決めます。やってはいけない向き合い方を挙げておきます。

• AIの採点結果を、根拠を確かめずに成果の指標や人事の判断に使う
• 記録に残る情報の種類を決めないまま、会話の全文を保存し始める
• 記録を読める人を全社に開き、書き出しの履歴も残さない
• 公開されている勧告と利用中の版を突き合わせる担当を決めない
• ライセンスの範囲を確かめずに、有償の機能の部分まで社内に配る
• 記録があるから原因は分かるはず、と人の確認の手順を省く

裏を返せば、人が決める範囲ははっきりしています。何を残すか、誰が見るか、いつ止めるか、誰が責任を取るか。この四つは、AIにも道具にも委ねません。道具に任せてよいのは、人が決めた範囲で、決めた形の記録を漏れなく残し、速く探せるようにする部分です。

• Langfuseの機能・ライセンス・勧告は、GitHubのリポジトリとその中の文書、事業者の公式ページを2026年10月16日に確かめた範囲に基づきます。内容は変わる可能性があります
• 勧告の内容は概要です。修正版が出ているか、自社の構成に当てはまるかは、公開情報で確かめてください
• この記事は防御と評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Langfuseは、AIアプリの会話、道具の呼び出し、時間と費用を記録し、評価と改善、不具合の原因追跡を支えるOSSです。自社に置く形と、事業者が運用する形があり、記録の保存場所を選べます。「昨日まで動いていたのに急に動かない」という相談に、事実の並びで答えるための土台になります。

一方で、判定は「注意付き」です。ライセンスの表記は自動で判別できず、実際はMITと一部の別ライセンスの組み合わせでした。インストール時に自動で動く処理が書かれており、公開された勧告が4件あります。使うなら、記録に何を残さないかを決め、見る人を役割で絞り、版と勧告を追う。そのうえで、記録は事実の並びであって原因の説明ではないという前提を共有しておくこと。これが、AIの動きを記録する道具との付き合い方です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。