English version

Webから情報を取る処理を、LLMに毎回「生HTMLを読ませて頑張らせる」形で組むと、だいたい高くて遅くて壊れやすいです。 しかも、同じサイトを何度も読むユースケース（ニュース監視、ドキュメント追跡、価格改定検知など）だと、同じ失敗を何度も繰り返します。

この手の問題は、気合のスクレイピングテクで解決するというより、「一度うまくいった抽出方法を“道具”として固定化し、次回以降は再利用する」と割り切った方が素直に効きます。 この記事では、Web→Adapter→Tool→Agentという変換パイプラインで、スクレイピングを学習で道具化する設計をまとめます。

元々の着想は、以前の記事で紹介した web2cli （GitHubリポジトリ ）です。 あの記事の「Every website is a Unix command」という思想を、エージェント運用（再訪/トークン/ドリフト）に寄せていくと、だいたいこの方向に収束します。

最近、その延長線として self-learning-web-adapter という自己学習型スキル（skill: エージェントに渡す手順とツールのパッケージ）を追加しました。 スキル本体は skills/self-learning-web-adapter に置いてあります。

最近、Ethereum 周りを追っていると、MEV （Maximal Extractable Value）という言葉を避けて通れなくなりました。

MEVは「チェーン上の取引から追加利益を抜く」話なので、投資というよりトレーディング戦略に近い領域です。

自分が最初にMEVを追い始めたとき、「結局どのプレイヤーが、何を根拠に、どこで利益を取っているのか」が整理できずに迷子になりました。

この記事では、話を追いやすいように、

• MEVが何か（まず用語と発生源）
• MEVのプレイヤーと市場構造（誰が儲けて、誰が負担するか）
• 「MEVを獲得する」ための投資戦略（資本配分、期待値、勝ち筋、リスク管理）

だけに絞って、全体像を作ります。

注意: 本記事は教育目的の解説であり、特定の銘柄・商品・取引の推奨ではありません。MEVは損失や法務・倫理リスクもあります。

フェルミ推定 って、雑に言うと「ざっくり妥当な数字を出す技術」です。 市場規模、工数、必要人員、処理能力みたいな話で、まだ正確なデータが揃っていない時にかなり便利です。

ただ、LLM（Large Language Model: 大規模言語モデル）にこの手の仕事を任せると、別の問題が出ます。 数字自体はそれっぽく見えても、「何を根拠にその数字になったのか」が残らないと、あとから見直せません。

そこで、自作スキル fermi-estimation を作りました。 狙いは、フェルミ推定をうまくやることそのものではなく、推定結果をあとから監査できる形で残すことです。 ここで言う監査可能性とは、あとから見直せる、反論できる、再計算できることです。

Anthropic の Agent Skills overview を読んでいて、これは大きなフレームワークから入るより、まず最小構成で動きを見た方が早そうだなと思いました。

今回は、公式仕様を完全に再現する実装ではなく、Agent Skills の考え方を理解するためのローカル実験として作ります。

Agent Skills は、ざっくり言うと「エージェントに渡す再利用可能な作業手順」です。毎回長いプロンプトを書く代わりに、よく使う手順をスキル（skill: 再利用できる手順書の単位）として切り出しておくイメージです。

本記事では、Python だけで動く「最小のスキル対応エージェント」を作ります。前半で「スキルを見つける」「選ぶ」「実行する」という流れをローカルで再現し、後半で実際に LLM（Large Language Model: 大規模言語モデル）へ接続するところまでやります。

macOS同士（Apple Silicon）のマシンをTailscale でつないでいます。 Eternal Terminal （GitHub: MisterTea/EternalTerminal ）で接続しようとすると、Receiving client id から進まない沼にハマりました。

結論から言うと、この記事の時点では完全解決していません。 ただ、観測できた挙動と切り分けの手順を整理すると「どこが壊れていそうか」をかなり狭められます。ムダに時間を溶かさず、次のアクションへ進むための記事です。

本文中のホスト名とIPはダミー化しています（例: server, 100.64.0.10）。

補助金・助成金って、知ってる人は当たり前に申請していて、知らない人はそもそも存在に気づかない、みたいな情報だと思っています。 一方で、いざ調べ始めるとページが散らばっていたり、年度や公募回で要件が変わったり、PDF（公募要領）に大事なことが書いてあったりで、地味に時間が溶けます。

そこで「候補を集めて、要点を揃えて、公式リンクに戻れる」くらいの道具が欲しくて、自作スキル jp-grants を作りました。 LLM（Large Language Model: 大規模言語モデル）に聞くとしても、最終的に公式ページへ着地できないと怖いので、URLと根拠を残す方針です。

AI コーディングツールが当たり前になってきて、.env（環境変数ファイル）をそのまま置く怖さが目に見えるようになりました。

ファイルが読めるなら、秘密も読めます。ここはAI時代のセキュリティ として、無視しにくい問題だと思います。

この記事では、enject （旧enveil）を中心に、「AIが読める場所に秘密を置かない」という発想を整理します。

（補足）プロジェクトは以前 enveil という名前でしたが、現在は enject にリネームされています。

その上で、dotenvx を比較対象として出し、チーム/CIまで含めた運用で何が変わるかも見ます。

ターミナルの出力は、必要な情報があるのに長すぎる。特にテスト失敗やビルドエラーのとき、欲しいのは「どこで落ちたか」と「その前後」だけです。

そこで試したのがAISH公式サイト で紹介されているAISH（PTY-first shell wrapper / “signal, not noise”）です。AISHリポジトリ のREADMEを見ると、PTY（擬似端末）でコマンドを実行しつつ、出力を完全保存し、デフォルトは要約だけ出す設計になっています。

このツールは「AIが読むための出力設計」ではなく、「人間が読むべき場所だけ残す」ための設計です。ログを削らずに残しつつ、読むべき場所だけ短く出す。ここが一番の価値だと思います。

Webから情報を取る方法って、極端に寄りがちです。

• API（Application Programming Interface: 提供元が用意する機械向けの窓口）があるサイトはAPIを叩く
• APIがない/高い/制限がキツいと、ブラウザ自動化（Playwrightなど）に寄る

でも、ブラウザ自動化は重い。 特にAIエージェント（AI agent: LLMが外部ツールを使って作業する仕組み）に組み込むと、遅い・高い・壊れやすいの三拍子になりがちです。

そんな中で見つけたのが、web2cli です。 コンセプトはREADMEに書かれている通りで、かなり強い。

“Every website is a Unix command.”

ここで言うUnixコマンド（Unix command: 標準入力/標準出力でつなげられる、いわゆるCLIコマンドの作法）としてWebを扱えるようにする、という話です。

Agent Client Protocol （ACP）は、コードエディタ/IDEとコーディングエージェントの通信を標準化するプロトコルです。最近はAIエージェントの選択肢が増えましたが、実際の連携は各エディタの個別実装に依存しがちです。本記事では、エディタ開発者がすぐに統合を始められる粒度で、仕様の要点と実装の入口をまとめます。仕様の出典は公式ドキュメント とGitHubのリポジトリ です。

結論だけ言うと、ACPは「エディタとエージェントの間に共通語を作る」ための仕組みです。結果として、AI やLLM エージェントの乗り換えや、異なるエディタ間での互換性が取りやすくなります。