0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@TaichiEndoh(遠藤 太一)

ループエンジニアリング - 明日のルールは昨日のログに書いてある。ただし、そのログにはAPIキーも書いてある

0
Posted at

明日のルールは昨日のログに書いてある。ただし、そのログにはAPIキーも書いてある

ループエンジニアリング 前編：ログを読ませる前に、ログを読む
対象読者：AIコーディングツールを日常的に使っている人／これから「ループエンジニアリング」を試そうとしている人
読了時間：約7分

この記事のポイント（3行）

  • AIとの会話ログを分析させて自分用のルールを自動更新する手法（ループエンジニアリング）は、実際に効きます。提唱者の原文プロンプトも公開されています
  • ただしそのログには、APIキー・顧客のメールアドレス・社外秘のコードが入っている可能性があります。Five Eyes（米英豪加ニュージーランドの情報機関）の合同ガイダンスが、まさにこの点を名指しで警告しています
  • ログを外に出す前に自分で中身を確認するスクリプトを書きました。通信を一切しないので、実行しても何も外に出ません

⚠️ 先に、大事な前置き

この記事は筆者の現時点での個人的見解です。法的助言ではありません。

所属先のデータを扱う場合は、必ず自組織の情報システム部門・情報セキュリティ責任者・医療機関であれば医療情報安全管理責任者に確認したうえで判断してください。筆者は、この記事の内容を実際の業務で使われたことに起因するいかなる損害についても責任を負いません。

また、ツールの仕様は頻繁に変わります。この記事は2026年8月時点の一次情報に基づいています。実行前に必ず最新の公式ドキュメントを確認してください。

1. きっかけ

医療機器のログを見る仕事を、11年やってきました。

透析装置も人工呼吸器も、動いている間ずっとログを吐き続けます。そして現場でいちばん多いのは、「ログは取れているのに、誰も読んでいない」という状態です。何かが起きてから、初めて過去のログを遡る。そのときにはもう、原因になった条件は思い出せなくなっている。

先日、AI開発の界隈で「ループエンジニアリング」という言葉を見かけました。中身を読んで、既視感で少し笑いました。**「AIとの会話ログを、AI自身に読ませて、次のルールを作らせる」**という話だったからです。

やっていることは、機器のログレビューとほとんど同じです。ただし、決定的に違う点が1つありました。AIとの会話ログには、機器のログには入っていないものが入っています。

そこから先が、この記事の本題です。

2. 🔰 ループエンジニアリングとは何か

用語の定義から始めます。ここは公式の記述があります。

Anthropic は自社ブログで、ループを次のように説明しています。

loops as agents repeating cycles of work until a stop condition is met
（停止条件を満たすまで作業のサイクルを繰り返すエージェント、としてのループ）

出典：Anthropic「Loop engineering: Getting started with loops」（2026年6月30日）
https://claude.com/blog/getting-started-with-loops

IBM はもう少し実務寄りに定義しています。

the practice of designing agentic workflows, or loops, that iteratively guide AI agents toward completing user-defined goals with minimal human intervention
（人間の介入を最小限に抑えながら、AIエージェントをユーザーが定めたゴールへ反復的に導くワークフロー＝ループを設計する営み）

出典：IBM Think「What Is Loop Engineering?」（2026年7月17日）
https://www.ibm.com/think/topics/loop-engineering

つまり、プロンプトを人間が毎回打つのをやめて、打つ役目を仕組みに置き換えるという話です。

Claude Code を作った Boris Cherny 氏も、公開インタビューで「もう自分は Claude に直接プロンプトを書いていない。ループを書いていて、そのループが Claude にプロンプトを出す」という趣旨の発言をしています（複数の公開インタビューで同趣旨の発言が確認できますが、逐語の表現は媒体によって揺れがあります）。

参考：WorkOS「Boris Cherny on Claude Code」
https://workos.com/blog/boris-cherny-claude-code-acquired-interview-takeaways

3. 🔧 いちばん簡単な入口：1行のプロンプト

具体的な手法として広く共有されているのが、エンジニアの Martin Alderson 氏がブログで公開したプロンプトです。原文はこれです。

please search through my claude jsonl history files for this project, and analyse improvements to the current claude.md file. Note any times I get frustrated or any patterns of me asking the same thing between sessions

日本語にするとこうなります。

このプロジェクトの claude の jsonl 履歴ファイルを検索して、いまの claude.md の改善点を分析してください。私が苛立っている箇所と、セッションを跨いで同じことを聞いているパターンを挙げてください

出典：Martin Alderson「Self-improving CLAUDE.md files」（2026年2月8日）
https://martinalderson.com/posts/self-improving-claude-md-files/

「私が苛立っている箇所」を探させるという発想が、この手法のいちばん賢いところだと思います。

自分がAIに何を指示すべきかは、意外と自分では言語化できません。でも「同じ文句を3回言っている」という事実は、ログの中に客観的に残っています。何をルール化すべきかの答えは、たしかにログの中にあります。

ここまでは、素直にいい手法だと思います。

4. ⚠️ でも、その前に。そのログに何が入っていますか

ここからが、この記事を書いた理由です。

紹介されている手法の多くは、ログの中身を確認する工程を飛ばしています。「ログを読ませるだけ」と書かれていることが多い。

しかし、AIとの会話ログには何が残っているでしょうか。

政府機関が名指しで警告しています

米国 CISA・NSA、英国 NCSC、豪州 ACSC、カナダ、ニュージーランドの5か国が2026年4月に公表した合同ガイダンス「Careful Adoption of Agentic AI Services」に、次の記述があります。

Agentic AI systems often handle and contain a significant amount of sensitive information. This includes user information like prompts or goals, organisational data stored in a RAG system and secrets like API keys.
（エージェント型AIシステムは、多くの機微情報を扱い、かつ内部に保持していることが多い。これにはプロンプトや目標といった利用者の情報、RAGに保存された組織データ、そしてAPIキーのような秘密情報が含まれる）

出典：CISA他5か国合同ガイダンス「Careful Adoption of Agentic AI Services」（2026年4月30日）
https://media.defense.gov/2026/Apr/30/2003922823/-1/-1/0/CAREFUL%20ADOPTION%20OF%20AGENTIC%20AI%20SERVICES_FINAL.PDF

日本でも、IPA（情報処理推進機構）が「テキスト生成AIの導入・運用ガイドライン」で、機密情報の入力による外部流出リスクを運用時のリスクとして明記しています。

出典：IPA「テキスト生成AIの導入・運用ガイドライン」（2024年7月31日）
https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2024/f55m8k0000003spo-att/f55m8k0000003svn.pdf

実際に起きています

2025年1月、AIプラットフォームの DeepSeek がデータベースを外部に露出させ、100万件を超えるAIチャットログとAPIキーが含まれていたと報じられています。

出典：Proton「The hidden risks of AI chat logs」（2025年10月15日）
https://proton.me/blog/ai-chat-logs

これは「ログを外部に送った」ケースではなく「ログを保管していた側が漏らした」ケースですが、示していることは同じです。AIとの会話ログは、それ自体が機密情報の塊になっているということです。

🔧 だから、先に自分で見る

考えてみれば当たり前の話で、医療機器の世界では常識です。ログを外部の業者に渡すときは、まず何が入っているかを自分で確認します。渡してから「実は患者情報が入っていました」では取り返しがつきません。

そこで、ログを外に出す前に自分で中身を確認するスクリプトを書きました。やっていることは単純です。

  • 既定の保存場所から .jsonl ファイルを探す
  • ファイル数・合計サイズ・行数・推定トークン数を出す
  • APIキー・トークン・秘密鍵・メールアドレス・電話番号・ホームディレクトリのパスを検出して件数だけ報告する

重要な設計として、検出した値そのものは画面に出しません。「AWSアクセスキー 1件」とだけ出ます。画面に出した瞬間、スクリーンショットやターミナルの履歴という新しい漏洩経路が生まれるからです。そしてこのスクリプトは通信を一切行いません。読むだけ、数えるだけです。

実行するとこう出ます。

対象ファイル : 1本
合計サイズ   : 486B
推定トークン : 約212（日本語混在の粗い目安）

 外に出す前に確認すべきもの
      1件  AWS アクセスキー
      1件  認証情報の代入
      1件  メールアドレス
      1件  ホームディレクトリ

ただし、検出ゼロは安心の根拠になりません。このスクリプトが見ているのは既知のパターンだけです。社外秘のコード、顧客名、設計中の仕様、他社との会話。そういうものは正規表現では検出できません。最後は自分の目で見るしかない。

スクリプトは記事の末尾に置きます。

✅ 今夜やる、1つのこと

全部やる必要はありません。1つだけ選ぶなら、これです。

自分のログの合計サイズと、そこに何が入っているかを、1回だけ確認する。

下のスクリプトを走らせるだけで終わります。通信しないので、実行しても何も外に出ません。

結果を見てから、ループを組むかどうかを決めればいい。順番はそれで合っていると思います。

まとめ（前編）

  • ループエンジニアリングは実在する手法で、Anthropic と IBM の双方が公式に定義しています。有効性を疑う理由はありません
  • 入口は驚くほど簡単で、原文プロンプトも公開されています。「私が苛立っている箇所を探して」という発想が、この手法のいちばん賢いところです
  • ただし「ログを読ませるだけ」という紹介の多くは、ログの中身を確認する工程を飛ばしています
  • Five Eyes 合同ガイダンスは、エージェント型AIが保持する情報にAPIキーが含まれることを名指しで警告しています
  • 検出ゼロは安心の根拠になりません。正規表現で見つかるのは既知のパターンだけです

ログを見る前に、ログを見る。医療機器の現場では当たり前にやっていることが、AIの世界ではまだ手順に入っていない。それだけの話だと思っています。

📎 スクリプト

loglens.py として保存し、python3 loglens.py で実行します。標準ライブラリのみで動きます。追加インストールは不要です。

主なオプション：

  • --dir <パス> — 走査するディレクトリを指定（複数指定可）
  • --days 7 — 直近7日に更新されたファイルだけを対象にする
  • --show-context — 検出箇所の行番号を表示（値は伏字のまま）
  • --top 20 — 大きいファイルを何件表示するか

（※ここにスクリプト全文を貼り付けるか、GitHubに置いてリンクしてください）

次回（後編）

後編では、実装まわりの話を書きます。

  • Anthropic 公式は「この jsonl を直接パースするな」と明記している。では正しい入口はどこか
  • ルールを溜め続けると効かなくなる。500指示で最良モデルでも68%という実証データ
  • SessionEnd フックの既定予算は1.5秒。フックでLLMを呼ぶと静かに何も起きない
  • セッション間の連携は、もう公式機能になっている

⚠️ 最後にもう一度

この記事は筆者の現時点での個人的見解です。法的助言ではありません。

業務データを扱う場合は、必ず自組織の情報システム部門・情報セキュリティ責任者と相談したうえで判断してください。医療機関の場合は、医療情報安全管理責任者への確認を必ず行ってください。患者情報を含む可能性のあるデータは、いかなる形でも外部のLLMに入力しないでください。

ツールの仕様は変わります。実行前に必ず最新の公式ドキュメントを確認してください。

筆者は、この記事の内容を実際の業務で使われたことに起因するいかなる損害についても責任を負いません。

出典・参考資料（前編）

著者プロフィール

臨床工学技士 × AIエンジニア / 11年間、病院の医療機器の現場に立ち続けてきました。
いまはAIエンジニアとしても活動しながら、酪農学園大学の研究生として論文博士の取得を目指しています。
研究テーマの主軸は遺伝子医療の未来。そのうえで、医療現場と地続きにある病院のIT・サイバーセキュリティ・医療AI導入についても、現場で起きている課題と一次情報を突き合わせながら調べ続けています。

質問・誤りの指摘・「うちではこうしている」という事例の共有、いつでも歓迎します。

X：@endoh_taichi
Qiita：@TaichiEndoh

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?