LLMアプリには、通常のソフトウェアと同じ障害モードに加え、確率的な出力、モデルやプロンプトのドリフト、ツールの動作、検索品質、使用量に応じたコストという問題があります。スタックトレースに現れる障害もあれば、出力の評価、ユーザーからの報告、分布の変化で初めて分かる障害もあります。
従来の可観測性ツール（Datadog、New Relic、Sentry）なら、API呼び出しが8.4秒で成功し、入力に12,847トークンを使ったことは分かります。しかし、その応答が良かったのか、モデルがハルシネーションを起こしたのか、誤ったツールを呼び出したのか、先週から品質が変化したのかまでは分かりません。
本番環境のLLMシステムには、通常のトレース、メトリクス、ログに加えて、LLM処理の意味を表すデータが必要です。OpenTelemetryの生成AI向けセマンティック規約を出発点とし、製品に必要な場合に限って詳細を追加します。本記事で示すイベント形式は説明用の例です。AIExpertは、以下の全項目を実証する本番トレースやダッシュボードを公開していません。
LLMの可観測性は何が違うのか
LLMシステムには、従来の可観測性だけでは捉えられない特徴がいくつかあります。
個々の処理が非決定的。 同じ入力でも、呼び出すたびに出力が変わります。「正しく動作したか」という問いには、ステータスコードだけでは答えられません。
品質が主要な指標になる。 レイテンシーとコストも重要ですが、最も重要なのは品質であり、測定が最も難しいのも品質です。
複数ステップのトレース。 ユーザーのクエリから、複数のモデル呼び出し、検索、ツール呼び出しが発生することがあります。各操作は、より大きなトレースの一部です。
使用量に応じて変わるコスト。 コストは、モデル、トークン数、キャッシュ、ツール、プロバイダー固有の料金によって変わります。すべてに共通する呼び出し1回当たりの価格を仮定せず、実際に請求された使用量を呼び出し単位またはバッチ単位で帰属させます。
時間の経過に伴うドリフト。 モデルは更新され、プロンプトは進化し、入力分布も変化します。それに伴う品質の動きを確認できなければなりません。
機密性の高いペイロード。 入出力は診断に最も役立つデータである一方、特に機密性の高いデータでもあります。ログ記録には厳格な運用が必要です。
長時間の非同期フロー。 数分かかるエージェント実行、バックグラウンドのバッチジョブ、ストリーミング応答には、従来のリクエストとレスポンスを前提とする可観測性が適合しません。
計装は、こうした障害モードを明らかにできるよう設計します。どの障害モードが支配的かは、自社のトラフィックから判断する必要があります。
可観測性スタック
実用的なLLM向け可観測性の設計では、ワークロードとリスクに応じて、次のレイヤーから必要なものを選びます。
1. 呼び出し単位の計装。 すべてのLLM呼び出しから、レイテンシー、請求対象の使用量、モデルとリビジョン、ステータスなど、承認された運用メタデータを出力します。生の入出力は、その取得を別途正当化し、管理できる場合に限って取得します。
2. トレース単位の計装。 複数回の呼び出しからなるワークフローを1つのトレースに結び付けます。ユーザーのリクエストに対する呼び出しチェーン全体を確認できます。
3. アプリケーション単位のメトリクス。 機能別、ユーザー別、テナント別に集計します。
4. 品質モニタリング。 一部またはすべてを対象に、自動で品質を評価します。
5. ユーザーフィードバックの取得。 明示的なシグナル（高評価・低評価）と暗黙的なシグナル（再生成、離脱）を取得します。
6. アラート。 コストの急増、レイテンシーの悪化、品質の低下、エラー率の上昇をリアルタイムで通知します。
7. デバッグツール。 問題が起きたとき、権限を持つ対応者は、原因を理解するために必要な最小限の承認済み情報を調べられます。生の入出力が必ず存在し、いつでも閲覧できるという意味ではありません。
以下で各レイヤーを説明します。
呼び出し単位の計装
すべてのLLM呼び出しで、承認済みのメタデータレコードを生成します。次の例でコメントが付いたペイロードと識別情報のフィールドは、機密性の高い任意項目であり、デフォルトで収集するものではありません。
{
"call_id": "uuid",
"timestamp": "2026-08-04T14:23:45Z",
"trace_id": "uuid", // トレースとしてまとめるためのID
"span_id": "uuid", // 親子関係を表すID
"feature": "summarize_document",
"prompt_version": "v3.2",
"model": "provider-model-revision",
"provider": "anthropic",
"input_messages": null, // 任意。承認済みのサンプリング／マスキング済みペイロードだけ
"output_message": null, // 任意。承認済みのサンプリング／マスキング済みペイロードだけ
"input_tokens": 1842,
"output_tokens": 384,
"total_tokens": 2226,
"cost_usd": 0.0084,
"latency_ms": 2340,
"first_token_ms": 1240, // ストリーミング
"status": "success",
"error": null,
"subject_ref": "pseudonymous_ref", // 任意。目的別の検索に使う参照値
"tenant_ref": "tenant_scoped_ref",
"metadata": {
"session_id": "...",
"experiment_arm": "v3_test"
}
}
これはアプリケーションイベントの説明用の例であり、必須スキーマではありません。明確に定めた運用目的に必要な最小限のデータだけを取得します。生のプロンプトと出力は、明示的に取得を有効化する機密性の高いペイロードであり、デフォルトのテレメトリーではありません。
主な実装上の選択肢：
どこに記録するか。 選択肢：
- LLM向けの専用可観測性ツール（Helicone、LangSmith、Phoenix、Braintrust、Arize）。
- LLM向け機能を持つ一般的な可観測性基盤（Datadog LLM Observability、Sentry）。
- 自社のログまたはデータベース。
要件に基づいて選びます。OpenTelemetry経由のエクスポート、トレースとツール呼び出しの可視化、データ所在地、自社運用、マスキング、アクセス制御、保持と削除のAPI、モデル料金の更新、評価機能、総所有コストを比較します。専用ツール、既存のAPM、小規模な自社実装のいずれも妥当な選択になり得ます。採用を決める前に、エクスポートと削除をテストしてください。
どのように計装するか。 選択肢：
- アプリとLLMプロバイダーの間に置くプロキシ（Heliconeの方式）。
- アプリケーションコードをラップするSDK。
- LLMを呼び出すたびに手動で使うラッパークラス。
プロキシは計装を一元化できますが、ネットワーク経路と障害点が増えます。SDKによるラップは同一プロセス内で計装できますが、コードが統合先に依存します。手動のラッパーは精密に制御できますが、網羅性を確かめるテストが必要です。選んだ方式のオーバーヘッドと障害時の挙動を測定してください。
実用的な方法の1つは、アプリがLLMを呼び出す境界をSDKでラップすることです。計装箇所を1か所に集約し、すべての呼び出しをそこに通します。
何を記録するか。 ペイロードの取得を有効にする前に、データ分類と保持方針を適用します。GDPRの第5条に定めるデータ最小化と保存制限の原則は、可観測性データにも適用されます。
- 生のコンテンツよりもプロンプトバージョン、ハッシュ、トークン数、ポリシー決定、派生メトリクスを優先してください。
- ペイロードの取得が正当化される場合は、サンプリングし、エクスポート前にマスキングしたうえで暗号化し、アクセスを制限し、保持期間を短く設定してください。
- マスキング済みのコピーを記録したという理由だけで、検索可能な生データを保持しないでください。そうすると機密データの保管場所を再び作ることになり、独自の適法な目的と管理策が必要になります。
- エラー処理の経路でも、認証情報をログに残してはいけません。
- ストリーミングでは、最初のトークンまでの時間と、完了までの時間の両方を記録します。
トレース単位の計装
1つのユーザー操作に、多数のLLM呼び出しが含まれることがあります。トレース単位で計装しなければ、呼び出しログが大量にあっても、どの呼び出しがどのユーザー操作に属するか分かりません。
実装方法：
トレースIDの生成。 ユーザーリクエストの開始時に一意のトレースIDを生成し、後続するすべての呼び出しに渡します。
親子関係を持つスパン。 トレース内の各呼び出しはスパンIDを持ち、必要に応じて親スパンIDも持ちます。これにより、呼び出し階層を木構造で表せます。
操作の命名。 各スパンに名前を付けます（“summarize_document”、“extract_entities”、“tool_call:search”）。トレースには操作チェーン全体が表示されます。
UIに表示するトレースの例：
Trace abc-123 (12.3s total)
├─ classify_intent (450ms) [small-model-revision]
├─ retrieve_documents (1.2s) [embedding + search]
├─ generate_response (8.5s) [generation-model-revision]
│ ├─ tool_call: search_internal (320ms)
│ ├─ tool_call: lookup_customer (180ms)
│ └─ generate_final_text (7.5s)
└─ judge_response_quality (2.1s) [claude-haiku-4-5]
これで、ユーザーのリクエストに対してシステムが実際に行った処理を確認できます。遅い呼び出し、高コストな呼び出し、失敗した呼び出しを、前後関係とともに特定できます。
実装候補には、LLM向けの専用可観測性製品と、OpenTelemetryを使う一般的なAPMがあります。製品の一覧だけに頼らず、実際の用途を代表する試験で、トレースコンテキストの伝播、ツール呼び出しの表現、エクスポート、マスキング、削除、アクセス制御、障害時の挙動を検証してください。
アプリケーション単位のメトリクス
個々の呼び出しに加え、次の指標を集計します。
機能別。
- 呼び出し数。
- 平均応答時間。
- p50、p95、p99の応答時間。
- リクエストあたりの平均コスト。
- エラー率。
- 品質スコア（測定されている場合）。
ユーザー／テナント別。
- ユーザー1人当たりの1日当たりの呼び出し数。
- ユーザーあたりのコスト。
- 利用量の多いユーザーと、不正利用のパターン。
モデル別。
- モデル別の呼び出し量。
- モデル別のコスト構成比。
- モデル別のエラー率。
- モデル別の品質（測定されている場合）。
機能 × モデル別。
- どの機能がどのモデルを使っているか。
- どの処理を低価格モデルへ移せる可能性があるか。
これらのダッシュボードは、どの機能のコストが高いか、どの機能が遅いか、どこを最適化すべきかという運用上の判断に役立ちます。
品質モニタリング
最も難しいレイヤーは、自動品質評価です。
評価は、定義済みのデータセットに対して実行します。オンラインの品質モニタリングでは、本番トラフィックを評価します。
手法：
サンプルをLLMで判定する。 トラフィック量、リスク区分、プライバシー上の制約、検出対象、予算に基づいてサンプルを定義します。対象となる事例で調整済みの判定モデルを使い、判定が分かれる事例や影響の大きい事例には人による確認を残し、結果をプロンプトとモデルのバージョン別に追跡します。判定モデルには、提示位置、冗長さ、自身の出力を優先するバイアスがあります。判定結果は検証すべき測定値であり、正解そのものではありません。
暗黙的なシグナル。 再生成、離脱、エラー率、完了までの時間、後続メッセージの頻度を追跡します。弱いシグナルですが、低コストで取得できます。先行指標として使います。
ユーザーによる明示的なフィードバック。 高評価・低評価、「役に立ちましたか」ボタン、明示的な問題報告などです。シグナルは最も強い一方、得られる量は最も少なくなります。
パターン検出。 特定の好ましくないパターン（「お手伝いできません」「私はAIです」、繰り返される拒否）を自動で検出します。一部の回帰をすぐに捉えられます。
実装記録には、サンプリング規則、除外データ、評価基準、判定モデルのバージョン、人が判定したキャリブレーション用データセット、不確実性、集計期間、アラート閾値、コスト上限を記載します。変化を検出する閾値は、ベースラインを繰り返し測定した結果と、回帰を見逃した場合の重大性から定めます。別のワークロードからコピーした割合には、統計的にも事業上も意味がない可能性があります。
コストの可観測性
再試行、ループ、想定外に長い入出力、振り分けの変更、プロバイダー料金の改定により、コストが急増する場合があります。一律の倍率を仮定せず、各原因を直接検出してください。
コストの可観測性を構成するレイヤー：
呼び出し単位のコスト。 ログ記録時に各呼び出しのコストを計算し、すぐに集計できるようにします。
予算アラート。 機能別、テナント別に日次、週次、月次の予算を設定し、予測のばらつきと業務上の重要度に基づいて、警告と制限を適用する閾値を決めます。
異常検出。 トラフィック構成が同じベースラインとコストや使用量を比較します。また、1回の実行が異常な状態に陥らないよう、ループ、トークン、ツール、再試行、実行時間、支出を個別に制限します。
コストの帰属。 機能別、テナント別、ユーザー別にコストを集計し、コストを大きく消費している対象を特定します。
予測。 現在の推移が続いた場合、月末の請求額がいくらになるかを予測します。
有用なダッシュボードの例は、今日のコスト、今週の残り期間の予測、先週の実績を機能別の内訳とともに1つのパネルに示すものです。
予算上限は、実測したトラフィックと業務上の重要度から決めてください。「10倍になったら停止」という一律の規則では、対応が遅すぎるか、必須のワークフローまで止めるおそれがあります。アラート、スロットリング、重要でない処理での低価格モデルへの切り替え、最後にサーキットブレーカーという段階的な制御を優先します。
レイテンシーの可観測性
LLMのレイテンシーは、一般的なAPIより複雑です。
総レイテンシー。 リクエストから最終応答までの時間です。
最初のトークンまでの時間（TTFT）。 ストリーミングでは、ユーザーに最初の文字が表示されるまでの時間です。チャットのUXでユーザーが感じる待ち時間を大きく左右します。
最後のトークンまでの時間（TTLT）。 応答が完了するまでの時間です。
1秒当たりのトークン数。 出力速度です。モデルによってストリーミング速度は異なります。
ツール呼び出しのレイテンシー。 エージェントのフローにおいて、LLM呼び出しに対してツール呼び出しにどれだけ時間を費やしたかを示します。
これらをすべて追跡してください。最適化するメトリクスによって、取るべき対策は異なります。
ユーザー向けチャットでは、TTFTは重要なインタラクション指標の1つです。ただし、完了までの総時間、出力速度、中断、タスクの成功、アクセシビリティも重要です。1つのレイテンシー指標がすべてのインターフェースで支配的だと仮定せず、観測したユーザー行動から目標を決めてください。
バッチ処理では総所要時間も重要ですが、スループットのほうが重要です。
エージェントでは、ツール呼び出しのレイテンシーが支配的になることがよくあります。ツールが遅ければ、LLMを最適化しても効果はありません。
エラーの可観測性
LLM固有のエラー：
APIエラー。 レート制限、認証失敗、サーバーエラーです。一般的なAPIと変わりません。
検証エラー。 構造化出力がスキーマに適合しなかった場合です。機能別に発生頻度を追跡します。
コンテンツフィルターエラー。 プロバイダーがリクエストをブロックした場合です。プロンプトの問題を検出できるよう追跡します。
ツールエラー。 特定のツールが失敗した場合です。ツール別に追跡します。
品質エラー。 判定用LLMが出力を不良と評価した場合です。時間の経過に伴う変化を追跡します。
ハルシネーションのシグナル。 モデルがソースにない内容を主張した可能性を検出します。自動検出は困難ですが、近似はできます。
コストエラー。 呼び出しのコストが予想を大幅に上回った場合です。多くの場合、不具合を示しています。
エラーの種類ごとにダッシュボードを用意し、必要に応じてアラートを発報します。
デバッグツール
問題が起きたときは、原因を見つけて理解する必要があります。デバッグ機能には次のものがあります：
トレース検索。 テナントのデータを必要以上に開示せず、トレースID、承認された仮名化済みの主体参照、タイムスタンプでイベントを検索します。
呼び出し詳細画面。 デフォルトではメタデータだけを表示します。役割の確認、アクセスログ、目的の制限、保持方針の下で承認され、最小化されたリクエストとレスポンスのフィールドだけを表示します。多くの環境では、ペイロード全体を保持すべきではありません。
トレースタイムライン。 複雑なフローでは、呼び出しチェーンを視覚的に確認します。
制御された再実行機能。 承認され、最小化された入力を、ツールを無効化またはサンドボックス化した隔離環境で再実行できるようにします。本番の呼び出しを、実際の外部操作が発生する状態で再生してはいけません。再実行に便利だというだけで、ペイロードの保持が正当化されると考えてはいけません。
差分表示。 2つの呼び出しを並べ、同じプロンプトの異なるバージョンや異なるモデルなどを比較します。
承認された内容または派生フィールドによる検索。 テレメトリーシステムを顧客のプロンプトを無制限に収めるコーパスにせず、定義済みのパターンだけを検索します。認可、最小化、インデックス化、保持、アクセスログは、保存時だけでなく検索時にも適用されます。
こうした機能は製品によって大きく異なります。実際の用途を代表する試験で検証し、統合、保存、プライバシー審査、移行、運用にかかる作業も比較に含めてください。表示価格だけでは、購入のほうが安いとは証明できません。
プライバシーとPII
LLMの可観測性ログは機密性の高いデータです。入力に個人データが含まれ、出力がそれを引用する場合もあります。デバッグのために生のペイロードを取得する案が出ても、それが当然に必要または適法になるわけではありません。まず目的を定め、合成データでの再現、派生フィールド、短期間だけ保持する管理されたサンプルを検討してください。
実践策：
仮名化／トークン化。 直接識別子を目的別のトークンに置き換え、再識別のための対応表を別途保護します。再識別できる可能性が残る場合、そのレコードは引き続き個人データであり、「非PII」と呼べる匿名データではありません。
ログ記録時のマスキング。 可観測性データの保存先に届く前にPIIを検出してマスキングします。メールアドレス、電話番号、SSNなどの特定パターンをプレースホルダーに置き換えます。
テナント分離。 マルチテナント環境の可観測性データをテナント別に分離します。あるテナントのデータが別のテナントから見えないようにします。
アクセス制御。 生の入出力を閲覧できる人を制限し、そのアクセスを記録します。
保持方針。 X日を過ぎたログは削除するか、コールドストレージへ移します。PIIの保持は、多くの法域で法的な制限を受けます。
削除と処理制限のワークフロー。 その目的に使用することが承認された識別子でテレメトリーレコードを検索できるようにし、主要ストレージ、インデックス、エクスポート、バックアップのすべてに、法律専門家が定めた措置を実装します。口語的な「忘れられる権利」を無条件の約束に置き換えてはいけません。GDPRに基づく消去には条件と例外があります。
システムには、扱う個人データと処理目的に見合った管理策が必要です。具体的な組み合わせは異なりますが、テナント分離、認可されたアクセス、データ最小化、保持、削除と処理制限への対応、監査可能性について、生のペイロードをテレメトリーとして取得する前に決定してください。欧州委員会は消去請求の条件と例外を要約しています。
アラート
アラートの対象となる閾値とシグナル：
コスト。
- 支出額または支出予測が、その機能の実績に基づく予算範囲を超えた場合。
- リクエスト1件当たりのコストが、ワークロード固有の上限を超えた場合。
- 変化率が、同じトラフィック構成のベースライン範囲を超えた場合。
レイテンシー。
- テールレイテンシーが、製品の実績に基づくサービス目標を外れた場合。
- 最初のトークンまたは完了までの時間が、そのインタラクション固有の目標を外れた場合。
- ツールのタイムアウトまたはキュー待ち時間が、ベースライン範囲から外れた場合。
エラー率。
- エラー率が、ワークロードのエラー予算を超えた場合。
- 検証エラーやレート制限など、特定のエラー種別がベースライン範囲から外れた場合。
品質。
- キャリブレーション済みのメトリクスが反復実行時のばらつきを超えて変化した場合、または安全性を評価する区分で許容されない結果が1件でも記録された場合。
- ユーザーフィードバックの否定的評価率がベースラインを超えた場合。
- 再生成率が基準値を超えた場合。
パターン。
- 特定の好ましくないフレーズの出現頻度が上がった場合。
- 入力分布の突然の変化。
各アラートには、対象機能、集計期間、観測値と期待値、影響を受ける区分、トレースへのリンク、ランブックを含めます。ループまたは再試行のテレメトリーに裏付けられていない段階で、アラート文に「暴走」と原因を書いてはいけません。
マルチテナントの考慮事項
B2B SaaSアプリの場合：
テナント別のメトリクス。 各顧客は自社の使用量、コスト、品質を確認できます。
テナント別のアラート。 各テナントの閾値に応じて通知します。
テナント別のデバッグ。 適切なアクセス制御の下で、サポート担当者が顧客のトレースを確認できます。
テナント別の設定。 顧客によって、モデル、プロンプト、ポリシーが異なる場合があります。可観測性レイヤーにその違いを反映します。
マルチテナントシステムでは、サポートや請求のためにテナントの帰属情報と分離が必要な場合があります。ただし、生のトレースへのアクセスまで当然に正当化されるわけではありません。サポート担当者には必要最小限のデータと機能だけを提供し、アクセスを記録し、機密性の高いペイロードを扱う場合のエスカレーション経路を用意してください。
ツールエコシステム（2026）
執筆時点におけるLLM向け可観測性ツールの概観：
LLM向けの専用可観測性ツール：
- Helicone、LangSmith、Phoenix（Arize）、Braintrust、PromptLayer、Weights & Biases Weaveは、上記の要件に照らして検証できる候補です。
LLM向け機能を持つ一般的なAPM：
- Datadog LLM ObservabilityとNew Relic AI Monitoringは、組織がすでにそれらのプラットフォームを使っている場合の候補です。
- OpenTelemetryと任意のAPM。 OTelには生成AI向けのセマンティック規約があります。この規約に沿って計装し、対応する多くのツールで表示できます。
自前構築：
- 対象範囲が限定されたシステムなら、必要な分離、アクセス、保持、削除、インデックス化の管理策を実装すれば、小規模なデータベースでも十分な場合があります。
- 検索と表示のための簡単なUIを追加します。
- 既存のログ基盤に統合します。
採用した選択肢、却下した代替案、データフローの審査、離脱時のエクスポートテスト、再評価日を記録します。すべてのチームに適したデフォルトの移行経路はありません。
実践的な導入手順
一般的な日程に当てはめるのではなく、依存関係とリスクに応じて順序を決めます。
ステージ1： 要件に照らして候補を選び、合成した機密情報を含まないトレースで試します。取り込みだけでなく、エクスポート、アクセス、マスキング、保持、削除、障害、離脱時の経路も検証してください。
ステージ2： 機能別コスト、レイテンシー分布、エラー分類、モデルとプロンプトのバージョン、テレメトリー欠損率など、定義済みのサービス目標に対応するダッシュボードを追加します。
ステージ3： コスト、ループ、レイテンシー、エラー分類について、ワークロードの実績から導いたアラートを設定します。
ステージ4： 複数回の呼び出しからなるフロー全体でスパンを接続し、ツールとキューをまたいでトレースコンテキストが伝播することを検証します。
ステージ5： 承認済みの品質サンプリングを実装し、自動評価を人による判断に照らして調整します。
ステージ6： 解釈方法、プライバシー上の取り扱い、対応ワークフローが定義されている場合に限って、ユーザーフィードバックを追加します。
ステージ7： 認可とアクセス監査を備えたテナント別のビューとデバッグ機能を追加します。
各ステージの受け入れ記録には、テスト、データ分類、責任者、障害時の挙動、ロールバックを含めます。機能を省く場合は、明示的な根拠と代替となる管理策が必要です。
導入しないと何が起きるのか
LLM向けの可観測性が不十分なチームで繰り返し起きるインシデントの例：
-
ある機能が短い間隔で呼び出しを再試行し、請求を確認するまでに想定外の費用が積み上がる。
-
モデル更新によって挙動が変わったものの、リクエストにモデルのバージョンが記録されておらず、原因の特定が遅れる。
-
プロンプトの新しいバージョンで重要なフローが回帰したものの、デプロイと応答トレースをバージョン別に比較できない。
-
エージェントがループしているものの、ステップ数の上限とトレース単位の計装がないため、同じ状態の繰り返しを確認できない。
-
ツールの認証失敗で再試行が起きたものの、エラー分類と再試行のテレメトリーが関連付けられていない。
-
プロンプトインジェクションの経路で安全上問題のある情報開示が起きたものの、データリネージとポリシー判断のテレメトリーがないため、影響を評価できない。
これらは、テストすべき障害シナリオです。可観測性は検出と調査のための証拠を作りますが、シグナルに基づいて強制的な管理策が作動しない限り、根本の障害そのものは防げません。
インシデント前に計装する
LLM向け可観測性は、通常のAPMを置き換えるのではなく拡張するものです。ワークロードと脅威モデルに基づいて、呼び出し、トレース、品質、コスト、レイテンシー、エラー、デバッグに必要なシグナルを選び、テスト済みの対応策につなげてください。
本番で機能するという主張をするなら、シナリオ別の検出時間、トレースの完全性、測定可能な場合のアラートの適合率と再現率、予算管理の挙動、プライバシーテスト、復旧またはロールバックの証拠を示すべきです。リリース前に計装し、ランブックを演習し、実際に測定した結果だけを公開してください。
