# Do AI Coding Agents Log Like Humans? An Empirical Study > [!abstract] 概要 > ソフトウェアロギングは複雑なシステムの保守とデバッグに不可欠だが、AI コーディングエージェントがこの非機能要件をどう扱うかは明らかでない。先行研究は人間のロギング実践を特徴づけてきたが、AI コーディングエージェントの振る舞いと、それを統制する自然言語指示の有効性は未解明である。このギャップに取り組むため、我々は 81 のオープンソースリポジトリにまたがる 4,550 件のエージェント型プルリクエストの実証研究を行う。エージェントのロギングパターンを人間のベースラインと比較し、明示的なロギング指示の影響を分析する。その結果、58.4% のリポジトリでエージェントは人間よりもロギングを変更する頻度が低いが、変更する場合にはより高いログ密度を示すことがわかった。さらに、明示的なロギング指示はまれ(4.7%)かつ効果がなく、エージェントは建設的な要求の 67% に従わない。最後に、生成後のログ修正の 72.5% を人間が行っていることを観察した。人間は、明示的なレビューフィードバックなしにロギングとオブザーバビリティの問題を修正する「サイレントジャニター(silent janitors)」として振る舞っている。これらの知見は、自然言語指示における二重の失敗(すなわち、ロギング指示の乏しさとエージェントの低い遵守)を示しており、一貫したロギング実践を保証するには決定論的なガードレールが必要となりうることを示唆する。 ## 論文情報 - **タイトル**: Do AI Coding Agents Log Like Humans? An Empirical Study - **著者**: Youssef Esseddiq Ouatiti¹, Mohammed Sayagh², Hao Li¹, Ahmed E. Hassan¹ - **所属**: ¹Queen's University(カナダ・キングストン)、²ETS - Québec University(カナダ・モントリオール) - **媒体**: arXiv プレプリント(cs.SE)。ACM 形式の原稿(24 ページ) - **発表年**: 2026(arXiv v1 2026-04-10) - **arXiv ID**: 2604.09409v1 - **URL**: https://arxiv.org/abs/2604.09409 - **再現パッケージ**: 論文中で公開を明記([20]) ## 概要 AI コーディングエージェントが実リポジトリの PR でどうロギングするかを、同一リポジトリの人間 PR と比較した初の実証研究。AIDev データセットから 81 リポジトリ・エージェント PR 4,550 件・人間 PR 3,276 件を取り、ロギングの頻度・密度・書き方(RQ1)、ロギング指示の有無と遵守(RQ2)、生成後に誰がログを直すか(RQ3)を調べた。エージェントは書き方こそ人間に似るが、ログに手を付ける頻度が低く、指示はまれで守られず、事後の修正は人間が黙って担う、というのが結論である。 ## 問題設定 - エージェントは機能要件(テストを通す)だけでなく、オブザーバビリティのような**非機能要件(NFR)**も満たす必要がある。オブザーバビリティは主にロギングで実現されるが、人間のロギング実践も非形式的で、経験や暗黙知に依存し、情報不足と過剰ノイズのトレードオフを抱える。 - 既存研究はエージェント PR の機能的正しさや受理率を調べてきたが、オブザーバビリティの観点は手付かずである。エージェントが人間のロギング習慣を模倣するのか、開発者がそもそもロギング基準をエージェントに指示しているのかは不明である。 - LLM によるログ生成のベンチマーク研究(LANCE、UniLog、GPT-4o の過剰ロギング評価など)は孤立したデータセットに依拠しており、人間がレビューしマージする実際のエージェントワークフローでの振る舞いは調べられていない。 ## 提案手法 新手法の提案ではなく、実証研究の設計である。 - **データ収集**: AIDev データセットの AIDev-pop(100 スター以上。エージェント PR 33,596 件・人間 PR 6,618 件)から、500 スター以上で両方の PR を持つ 810 リポジトリに絞り、各 10 件以上のエージェント PR と人間 PR を持つ 130 リポジトリへ、さらに主言語が Python・Java・JavaScript/TypeScript のものへ絞って 81 リポジトリを得た。人間 PR のパッチは GitHub API で取得し、エージェント PR のパッチは AIDev に含まれる。 ![[_attachments/arxiv-2604.09409/fig01-data-pipeline.png]] *図1(Figure 1). データ収集パイプライン。AIDev-pop から共有リポジトリ、両 PR が各 10 件以上のリポジトリ、言語フィルタを経て 81 リポジトリの最終データセットに至る。* - **ログ文の検出**: 言語別の正規表現(Python の `logging.info` 等、Java の `LOGGER.warn` 等、JS/TS の `console.log` 等)で差分中のログ文変更を検出する。`System.out.println` のような汎用 print は本番レベルのロギングではないとして除外し、ビルド成果物・バイナリ・minify 済みコードも除く。380 差分の手動検証で適合率 96%・再現率 94%。両側ともログ変更の無い 4 リポジトリを除き、分析対象は 77 リポジトリとなる。 ![[_attachments/arxiv-2604.09409/table1-logging-regex.png]] *表1(Table 1). ログ文検出に用いた言語別の正規表現(大文字小文字を区別しない)。* ![[_attachments/arxiv-2604.09409/table2-extensions-exclusions.png]] *表2(Table 2). 走査対象の拡張子と、ノイズ削減のために除外したパス・接尾辞。* - **エージェント指示の収集**: 指示は 3 経路から集める。(1) PR に紐づく issue(タスク仕様)、(2) PR 作成時点でリポジトリにあったエージェント指示ファイル(`CLAUDE.md`、`.github/copilot-instructions.md`、`AGENTS.md`、`.cursorrules` など)、(3) エージェント PR へのレビューコメント。IDE のチャットなど非公開経路の指示は取れない。 ![[_attachments/arxiv-2604.09409/table3-instruction-files.png]] *表3(Table 3). エージェント別の指示ファイルと、その識別に使った正規表現パターン(Devin・Cursor・Copilot・Claude・Codex・共通の `AGENTS.md`)。* - **ロギング意図の分類**: GPT-4o・GLM-4.7・DeepSeek-V3.2 の 3 モデルに独立に分類させ多数決する、マルチエージェントの LLM-as-judge(LLM 陪審)方式で、各テキストを Add(ログ追加)・Remove(抑制)・Modify(既存ログの修正)・none に分類する。100 件の手動ラベルとの一致が Cohen's κ = 0.83 に達するまでプロンプトを反復改良した。 ![[_attachments/arxiv-2604.09409/fig02-llm-jury-prompt.png]] *図2(Figure 2). ロギング指示の識別に用いた LLM 陪審プロンプト。メタデータとしてテキスト種別(issue、repo_instruction、review_comment)を与える。* - **RQ1 の指標**: ロギング頻度(logging prevalence。ログ文を 1 つ以上追加・変更・削除する PR の割合)、ログ密度(1,000 変更行あたりの変更ログ文数)、メッセージ特性(文字数とログレベル)、構文上の配置(条件分岐・ループ・try/catch・非ネスト)。リポジトリごとに PR 中央値を取り、エージェント /(エージェント + 人間)の正規化スコアで比べる(0.5 が同等、0.5 超はエージェント側が大)。 ![[_attachments/arxiv-2604.09409/table4-log-levels.png]] *表4(Table 4). 言語別ログレベルの冗長度による並び(debug が最も冗長、error 系が最も低い)。* ![[_attachments/arxiv-2604.09409/table5-syntactic-contexts.png]] *表5(Table 5). 言語固有キーワードを統一的な構文文脈(条件分岐・ループ・try/catch・非ネスト)へ対応づける表。* - **RQ2 の方法**: タスク仕様(Copilot PR に紐づく issue)とリポジトリ指示ファイルの 2 チャネルを対象に、指示単位で意図(LLM 陪審)と強さ(Strong/Weak。第 1・第 2 著者の手動ラベル、κ = 0.96)を測り、PR 単位で指示の有無・ロギング変更の有無・遵守(最終差分が指示意図に合うか)を測る。 ![[_attachments/arxiv-2604.09409/fig09-rq2-approach.png]] *図9(Figure 9). RQ2 の手順。リポジトリ指示ファイルと紐づく issue から指示を抽出し、LLM 陪審でロギング関連か判定して Add・Change・Remove に分類する。* - **RQ3 の方法**: (1) エージェントが導入したログ文の履歴を初回コミットからマージまで追い、各変更をコミット作者のメタデータで人間かボットに帰属させる。(2) 全 4,550 PR のレビューコメントからロギング関連の指摘を LLM 陪審で抽出し、指摘者(人間/ボット)と意図を分類する。(3) Kaplan-Meier 生存分析で、初回コミットにログ変更を含む PR について、次にログが変更されるまでのコミット数を推定する。同じ手順を人間 PR にも適用して比較する。 ![[_attachments/arxiv-2604.09409/fig10-rq3-method.png]] *図10(Figure 10). RQ3 の方法。(a)(Figure 10a) レビューコメントとコード差分から、ロギング指示の抽出・生存分析・git blame による変更の帰属を行う流れ。(b)(Figure 10b)分析対象とする PR のライフサイクル(作成 t=0 からレビュー・追加コミットを経てマージ t=N まで)。* ## 新規性 - 成熟した人気リポジトリで、人間とエージェントのロギング実践を同一リポジトリ内で比較した初の分析だと主張する。 - ロギング指示の不足(指示ギャップ)と、指示とエージェント行動のずれ(遵守ギャップ)を定量化した。 - 生成後のロギング修正のライフサイクルを分析し、人間レビュアーが負う隠れた保守負担を数値化した。 - ベンチマーク上の LLM ロギング評価(LANCE・UniLog など)に対し、実 PR での現場分析(in-situ analysis)を補う位置づけである。 ## 実験設定 - **データ**: AIDev データセット。81 リポジトリ、エージェント PR 4,550 件、人間 PR 3,276 件。本文は収集期間を「2024 年 12 月から 2026 年 7 月」と書くが、論文は 2026 年 4 月付けであり、誤記の可能性がある。 - **対象言語**: Python、Java、JavaScript/TypeScript。 - **対象エージェント**: 指示ファイルの識別パターンとして Devin・Cursor・Copilot・Claude・Codex を扱う(表3)。脅威の節ではデータの基盤モデルとして Claude 3.5 Sonnet や GPT-4o を例示する。 - **統計**: 対応のあるリポジトリ単位比較の有意性検定、Pearson の χ² 検定、Cliff's δ、Spearman の順位相関、Kaplan-Meier 推定(scikit-survival)。 ## 実験結果 ### RQ1: エージェント PR のロギングは人間 PR とどう違うか - **ロギング頻度**: 77 リポジトリ中 45(58.4%)でエージェント PR の方がログを変更する割合が低く、29(37.7%)では逆、3 は同等である。差は有意(p = 0.019)で、中央値スコア 0.45 は典型的なプロジェクトでエージェントが約 16% 少なくログを変更することを意味する。リポジトリ別のロギング頻度の中央値は人間 23.5%、エージェント 18.5% である。 ![[_attachments/arxiv-2604.09409/fig03-logging-prevalence.png]] *図3(Figure 3). リポジトリ単位のロギング頻度の比較。(a) 人間 PR とエージェント PR の分布。(b) リポジトリごとの対応比較(横軸が人間、縦軸がエージェント)。* - **ログ密度**: 50.6% のリポジトリでエージェント PR の密度が高いが、差は有意でない(p = 0.274、中央値スコア 0.51)。両者ともログを変更する 67 リポジトリに限ると中央値スコアは 0.56 に上がり、エージェントは 1,000 変更行あたり約 30% 多くログを変更する。例として microsoft/ApplicationInsights-JS ではエージェント 12.90 対人間 1.03(スコア 0.93)である。 ![[_attachments/arxiv-2604.09409/fig04-log-density.png]] *図4(Figure 4). リポジトリ単位のログ密度の比較。(a) 分布(中央値は人間 1.29、エージェント 2.58)。(b) リポジトリごとの対応比較。* - **密度差は PR サイズの構成効果**: 両者ともログ密度は PR が大きいほど下がる。エージェント PR は小さい(変更行の中央値 1,279 対人間 2,770.5)。ログを追加する PR のうち 1,000 行以下はエージェント 46.8%、人間 33.0%、2,500 行超は人間 52.7%、エージェント 40.7% である。エージェントの方が小さい変更をする 48 リポジトリでは 65% 多くログを追加するが、エージェントの方が大きい変更をする 19 リポジトリでは 21% 少ない。2,500 行超の PR だけを見ると密度の中央値は 1.64 対 1.59 でほぼ一致する。著者は、開発者が小さく境界の明確なタスクをエージェントに任せ、大きな統合作業を人間が担う**選択的な委任(selective delegation)**の表れと解釈する。 ![[_attachments/arxiv-2604.09409/fig05-pr-size-vs-density.png]] *図5(Figure 5). PR サイズとログ密度の関係(PR 単位)。点は個々の PR、線は 12 個の対数等間隔ビンごとの中央値。* - **メッセージ長**: 中央値スコア 0.50 で、63.6%(49/77)のリポジトリで長さは同程度である。エージェントの方が明確に長いのは 22.1%(17)、人間の方が長いのは 14.3%(11)である。 ![[_attachments/arxiv-2604.09409/fig06-message-length.png]] *図6(Figure 6). リポジトリ単位のログメッセージ長の比較。キャプションは、両側に抽出可能なメッセージ文字列を持つ 57 リポジトリの結果だとする。* - **ログレベル**: `console.log` と ERROR の使用率が同程度のリポジトリはそれぞれ 71.4%、53.2%、DEBUG は 64.9% である。乖離は INFO と WARN に出る。INFO は人間の方が多く使うリポジトリが最も多く(24.7%)、WARN は同程度の割合が最も低い(48.1%。エージェント過多 29.9%、人間過多 22.1%)。手動確認では、「operation completed」のようなプログラム状態の確認メッセージが人間のログに多いことが差の一因とみられる。 ![[_attachments/arxiv-2604.09409/fig07-log-levels.png]] *図7(Figure 7). ログレベルごとに、使用率が同程度(灰)・エージェントが多い(青)・人間が多い(茶)リポジトリの割合。* - **配置**: try/catch と非ネスト(関数本体の最上位)での配置は 58.4%、59.7% のリポジトリで同程度である。一方、条件分岐で同程度なのは 46.7% で、人間の方が多く置くリポジトリが 28.6%、ループでは人間の方が多く置くリポジトリが 32.5% ある。エラー関連の文脈では人間に合わせるが、情報ログを置きがちな場所(ループなど)では控えめである。 ![[_attachments/arxiv-2604.09409/fig08-syntactic-context.png]] *図8(Figure 8). 構文文脈ごとの比較。左の棒は人間が多く使うリポジトリ、右の棒はエージェントが多く使うリポジトリ、中央は同程度の割合。* ### RQ2: 明示的なロギング指示はどれだけあるか - **指示はまれ**: 指示チャネル(紐づく issue またはリポジトリ指示ファイル)が観測できる 1,308 PR のうち、ロギング指示を伴うのは 4.7%(61 件)だけである。issue のみが 15 件、指示ファイルのみが 46 件で、重なりはない。 - **指示ファイルは後片付けの規則として働く**: 指示ファイルの Remove 指示 10 件はすべて 1 プロジェクト(dropseed/plain)のもので、「デバッグ用に使ってよいが、コミット前に消せ」という内容である。最終コードにデバッグ文はゼロで遵守率は 100% だが、著者はそもそも追加しなかっただけの「空虚な遵守(vacuous compliance)」で水増しされている可能性を認める。 ![[_attachments/arxiv-2604.09409/table6-instruction-compliance.png]] *表6(Table 6). 指示チャネル別の PR 単位のロギング指示と遵守。タスク仕様の遵守は Add 40.0%、Modify 37.5%、Remove 0.0%。リポジトリ指示の Add は 36 件中 3 件(8.3%)。* - **強さに関係なく遵守ギャップがある**: issue 経由の指示 15 件のうち 73.3%(11 件)は具体的な strong 指示だが、その遵守率は 27.3%(3/11)にとどまる。リポジトリ指示ファイルの 46 件はすべて strong だが、全体の遵守率は 6.5%(3/46)である。タスク仕様(Copilot の issue)は生成前にモデルから見えるが、指示ファイルが見えるかどうかはエージェントのワークフロー次第であり、不遵守には「表示されていない」と「表示されたが無視した」の 2 つの原因がありうる。 ![[_attachments/arxiv-2604.09409/table7-instruction-strength.png]] *表7(Table 7). 指示の強さと遵守の関係(issue 指示 15 件)。strong(ファイル・レベル・フレームワークを特定)11 件の遵守 27.3%、weak(「ログを追加」「オブザーバビリティを確保」など汎用)4 件の遵守 50.0%。* - **指示はロギング変更率を上げない**: 指示ありの PR がログを変更したのは 14.8%、指示なしでは 20.8% で、統計的な差はない(χ² = 1.32、p = 0.25)。 ![[_attachments/arxiv-2604.09409/table8-instructed-prevalence.png]] *表8(Table 8). ロギング指示の有無別の PR 単位ロギング頻度。* - 要約の節は「98.7% のエージェント PR にロギング指示が無い」とし、「建設的な要求の 67% に従わない」とする。98.7% は全 4,550 PR を分母にした値(61/4,550 ≒ 1.3%)と整合し、本文の 4.7%(分母 1,308)とは分母が異なる。67% は表7の issue 指示 15 件の遵守 5 件(33.3%)の裏返しと一致するが、本文はこの対応を明示しない。 ### RQ3: 生成後のロギングは誰が統制するか - **修正はどちらにも多いが、修正者が違う**: ログ変更を含む PR のうち、後続コミットで修正されるのはエージェント PR 77.2%(941 件中 726)、人間 PR 81.6%(766 件中 625)である。修正されたエージェント PR の内訳は人間のみ 54.5%、ボットのみ 35.1%、両方 10.3%。人間 PR は 97.8% が人間のみによる。ログ文単位では、エージェント PR への生成後の変更の 72.5% を人間が行う(人間 PR では 99.5%)。 ![[_attachments/arxiv-2604.09409/fig11-revision-flow.png]] *図11(Figure 11). 生成後のロギング修正の流れ。(a) エージェント PR、(b) 人間 PR。修正の有無と、修正した主体(人間のみ・ボットのみ・両方)の内訳。* - **修正は PR の初期に集中し、エージェントのログは「粘る」**: 両者とも修正は最初の数コミットで起きやすい。人間の生存曲線の方が速く深く下がり、人間が書いたログの方が頻繁かつ素早く修正される。エージェントの初期実装は後続コミットで変更されにくい。 ![[_attachments/arxiv-2604.09409/fig12-survival-curves.png]] *図12(Figure 12). 生成後のロギング安定性の Kaplan-Meier 生存曲線(エージェント対人間)。初回コミットにログ変更を含む PR を対象とし、ログを変更する最初の後続コミットをイベントとする。* - **明示的なフィードバックはまれ**: ロギングに関するレビュー指摘があるのは全エージェント PR の 2.18%、全人間 PR の 2.17% で差はない。ログ変更を含む PR に限っても 5.80% と 6.00% である。修正はレビューで依頼されず、後のコミットで直接行われる。指摘がある場合は多くがボットによる(エージェント PR 75.6%、人間 PR 81.1%)。エージェント PR では人間・ボットとも Modify が最多(47.4%、44.9%)で、Remove(28.9%、24.6%)、Add(23.7%、30.5%)が続く。 ![[_attachments/arxiv-2604.09409/table9-review-feedback.png]] *表9(Table 9). レビューコメントにおける明示的なロギング指摘の率(PR 単位)。* - **統制は大きな PR に集中する**: ログが修正されたエージェント PR の変更行中央値は 2,702、修正されなかった PR は 231 である(p < 0.001、Cliff's δ = 0.688)。人間 PR も 4,390 対 250(δ = 0.726)。PR サイズと生成後のログ変更量には強い正の相関がある(エージェント ρ = 0.648、人間 ρ = 0.667)。明示的な指摘も大きい PR ほど多い(エージェント 320 対 130 行、人間 890.5 対 114 行)。 ![[_attachments/arxiv-2604.09409/fig13-pr-size-vs-revision.png]] *図13(Figure 13). PR サイズと生成後のロギング修正の関係(エージェント/人間 × 修正なし/修正あり)。* ## 考察 - **ツール開発者へ**: 自然言語指示はエージェントのロギングを導く手段として信頼できない。プロンプトや `AGENTS.md` のようなコンテキストファイルだけで NFR を強制することはできず、オブザーバビリティに焦点を当てた静的解析(リンター)や CI/CD チェックを PR 提出前に通過させる、ガードレール駆動の開発へ移るべきだと著者は主張する。 - **研究者へ**: エージェントはエラーロギングは真似るが INFO ログを使わない。著者はこれを、モデルがロギングを障害を捕まえる事後対応の仕組みとして捉え、正常な状態遷移を追う先回り型の道具としては捉えていない兆候と解釈する。状態遷移ロギングを重視する学習データや報酬モデル、RLHF による開発者の好みの反映、静的解析や CI/CD を客観報酬にする RLVR で、制御フロー上の計装漏れを罰する方向を提案する。 - **実務者へ**: 人間が生成後のログ修正の 72.5% を黙って担う「隠れた保守税」がある。オブザーバビリティを PR レビューのチェックリストの第一級項目にし、計装の無いエージェント PR は差し戻してエージェントに直させるべきだとする。 - **妥当性への脅威**: 指示ファイルの不遵守はコンテキスト長の制約ではなく振る舞いの整合の問題だと著者は論じる(128k 以上のコンテキストとコンテキスト圧縮)。IDE チャットの一時的な指示は捕捉できないが、それが有効ならエージェント PR のロギング頻度はもっと高いはずだとする。正規表現はカスタムラッパー(`MyLogger.track()` など)を取りこぼしうる。対象は 3 言語・100 スター以上のリポジトリに限られる。 > [!contradiction] 明示的なロギング指示はログの量を増やすか > 本論文の実 PR では、ロギング指示の有無はロギング変更率に有意差を生まず(指示あり 14.8% 対 なし 20.8%)、リポジトリ指示ファイルの Add 指示の遵守は 8.3% にとどまる。一方 [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]] の統制実験では、オブザーバビリティを明示的に指示する observability-hinted プロンプトが生成ログ文を約 2 倍に増やし、適合率を下げる(量が質に勝つ)。前者は実運用の PR で指示チャネルの可視性が不確かな条件、後者は指示を確実に与えた再生成タスクであり、条件の違いで説明できる可能性がある。(status: open) ## 強み / 弱点・課題 **強み**: - 同一リポジトリ内で人間 PR とエージェント PR を対にして比べ、プロジェクト間の差を統制している。 - ログ密度の差を PR サイズの構成効果として分解し、単純な「エージェントは過剰にログを書く」という解釈を退けている。 - 生成・指示・生成後の統制というライフサイクル全体を 1 つのデータセットで追っている。 - 正規表現検出(適合率 96%・再現率 94%)と LLM 陪審(κ = 0.83)を手動ラベルで検証している。 **弱点・課題**: - ロギング指示を伴う PR が 61 件、issue 指示が 15 件と少なく、遵守率の推定は小標本に依存する。Remove の 100% 遵守は空虚な遵守の可能性を著者自身が認める。 - 指示ファイルがエージェントに実際に提示されたかを観測できず、「無視」と「未提示」を区別できない。 - 数値の記述に揺れがある。要約の「98.7% が指示を欠く」と本文の 4.7%(分母違い)、RQ1 要約の「58.2% のリポジトリで密度が高い」と本文の 50.6%・中央値スコア 0.56、図6 キャプションの 57 リポジトリと本文の 77、収集期間の「2026 年 7 月」など。 - 正規表現はカスタムラッパーや非標準ライブラリを取りこぼしうる。print 系を除外しているため、そうしたログ手段に依存するプロジェクトは過小評価されうる。 - 3 言語・100 スター以上のリポジトリに限られ、小規模リポジトリへの一般化は未検証である。 ## 関連 - 概念: [[ログ生成]] / [[エージェント型コーディング]] / [[コンテキストエンジニアリング]] / [[Harness Engineering]] / [[ログ解析]] - エンティティ: [[Youssef Esseddiq Ouatiti]] / [[Mohammed Sayagh]] / [[Hao Li (Queen's University)]] / [[Ahmed E. Hassan]] / [[Queen's University]] / [[École de Technologie Supérieure]] / [[AIDev]] / [[Claude Code]] / [[Cursor]] / [[Devin]] / [[Codex]] - ソース: [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]] ## 出典 - [[.raw/papers/arxiv-2604.09409.pdf]](論文 PDF 原本) - [[.raw/papers/arxiv-2604.09409.txt]](抽出テキスト) - https://arxiv.org/abs/2604.09409