<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Fragments of verbose memory</title><link>https://blog.tumf.dev/</link><description>Recent content on Fragments of verbose memory</description><generator>Hugo</generator><language>ja-jp</language><lastBuildDate>Thu, 19 Feb 2026 09:00:00 +0900</lastBuildDate><atom:link href="https://blog.tumf.dev/index.xml" rel="self" type="application/rss+xml"/><item><title>Confluxをリリース: AIコーディングハーネスを束ねる仕様駆動オーケストレーター</title><link>https://blog.tumf.dev/posts/diary/2026/4/11/conflux-first-release/</link><pubDate>Sat, 11 Apr 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/4/11/conflux-first-release/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/conflux-release-a-spec-driven-orchestrator-for-parallel-ai-development-2gbc">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>&lt;a href="https://github.com/tumf/conflux" target="_blank" rel="noopener noreferrer">Conflux&lt;/a>
 の最初のリリースを出しました。これは、&lt;strong>仕様駆動開発&lt;/strong>（先に仕様や変更の意図を定め、それに沿って実装と検収を進める開発スタイル）を前提に、AIコーディングエージェントの作業を並列に回し、実装・検収・アーカイブまで含めた開発フロー全体を前に進めるためのツールです。&lt;/p>
&lt;p>最近は、&lt;a href="https://docs.anthropic.com/ja/docs/claude-code" target="_blank" rel="noopener noreferrer">Claude Code&lt;/a>
 や &lt;a href="https://openai.com/index/openai-codex/" target="_blank" rel="noopener noreferrer">Codex&lt;/a>
、&lt;a href="https://opencode.ai/" target="_blank" rel="noopener noreferrer">OpenCode&lt;/a>
 のようなツールで「コードを書く」こと自体はかなり簡単になりました。こうしたツールは、LLMにツールを持たせて実装を進める&lt;strong>コーディングハーネス&lt;/strong>として見ることができます。一方で、実際の開発では&lt;strong>仕様をどう持つか、複数の変更をどう安全に並行させるか、どこで受け入れ判定をするか&lt;/strong>の方が難しいです。&lt;/p>
&lt;p>Conflux は、そこを埋めるために作りました。単発のコード生成ツールではなく、そうしたハーネスを前提に、変更を積み上げながら一定規模の完成品を育てていくための、現実的な&lt;strong>オーケストレーション層&lt;/strong>という位置づけです。&lt;/p>
&lt;p>&lt;img 
 src="https://github.com/tumf/conflux/raw/main/docs/images/conflux-tui.jpg" 
 alt="Conflux TUIスクリーンショット"
 loading="lazy"
 decoding="async"
/>
&lt;/p>
&lt;p>Conflux の見た目はこんな感じです。TUI（Text User Interface、ターミナル上で動くテキストベースのUI）として、change の進行状況や全体の流れを確認できます。&lt;/p></description></item><item><title>OpenFang — Rustで作られたエージェントOSを触ってみた</title><link>https://blog.tumf.dev/drafts/openfang-rust-agent-os/</link><pubDate>Tue, 31 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/drafts/openfang-rust-agent-os/</guid><description>&lt;p>&lt;img 
 src="https://blog.tumf.dev/images/openfang-rust-agent-os/cover-neon.png" 
 alt="OpenFang — Rustで作られたエージェントOSを触ってみた"
 loading="lazy"
 decoding="async"
/>
&lt;/p>
&lt;p>「エージェントフレームワーク」は乱立しているが、「エージェントOS」と名乗るものはまだ少ない。&lt;a href="https://www.openfang.sh/" target="_blank" rel="noopener noreferrer">OpenFang&lt;/a>
（GitHub: &lt;a href="https://github.com/RightNow-AI/openfang" target="_blank" rel="noopener noreferrer">RightNow-AI/openfang&lt;/a>
）はその一つで、&lt;a href="https://blog.tumf.dev/tags/rust/">Rust&lt;/a>
で書かれた32MBのシングルバイナリが、AIエージェントを24時間自律稼働させる基盤を丸ごと提供する。&lt;/p>
&lt;p>ちょうどエージェント基盤の選定をしていて、試してみたので感想をまとめる。&lt;/p></description></item><item><title>agent-execで長時間ジョブをWeb UI連携する: browser stateを真実にしない実装パターン</title><link>https://blog.tumf.dev/posts/diary/2026/3/22/agent-exec-long-running-jobs-ui-integration/</link><pubDate>Sun, 22 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/22/agent-exec-long-running-jobs-ui-integration/</guid><description>&lt;p>以前の記事「&lt;a href="https://blog.tumf.dev/posts/diary/2026/2/19/agent-exec-stdout-stderr-separation/">CLIの出力設計を間違えると、AIエージェントは何も読めない&lt;/a>
」では &lt;a href="https://github.com/tumf/agent-exec" target="_blank" rel="noopener noreferrer">agent-exec&lt;/a>
 の stdout/stderr 分離を、「&lt;a href="https://blog.tumf.dev/posts/diary/2026/3/15/agent-exec-job-finished-events/">agent-execにイベント通知が来た&lt;/a>
」では &lt;code>job.finished&lt;/code> 通知を紹介しました。&lt;a href="https://blog.tumf.dev/tags/ai/">AIエージェント&lt;/a>
に長時間処理を持たせるなら、次にぶつかるのがこの UI 連携です。&lt;/p>
&lt;p>今回はその続きです。テーマはもっと実務寄りで、&lt;strong>長時間ジョブを Web UI にどう接続するか&lt;/strong>。具体例として、&lt;code>fovm-editorial-desk&lt;/code> の &lt;code>Commit &amp;amp; Push&lt;/code> ボタンのように、押してすぐ終わらない処理をどう扱うかを整理します。&lt;/p>
&lt;p>言い換えると、&lt;code>job queue UI&lt;/code> や &lt;code>long-running job polling&lt;/code> の実装パターンの話です。単にボタンを押して API を叩くだけだと壊れやすいので、どこに真実を置くかを先に決めます。&lt;/p>
&lt;p>結論だけ先に書くと、&lt;strong>ブラウザの一時 state を真実にしない&lt;/strong>のが一番大事です。真実はサーバ側の job state に置いて、UI はそれを表示するだけにした方が壊れません。&lt;/p></description></item><item><title>Hermes Agent解説：FTS5＋LLM要約で「使うほど賢くなる」永続メモリの仕組み</title><link>https://blog.tumf.dev/posts/diary/2026/3/21/hermes-agent-persistent-memory/</link><pubDate>Sat, 21 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/21/hermes-agent-persistent-memory/</guid><description>&lt;p>AIエージェントを日常的に使っていると、「昨日教えたこと、もう忘れてるのか&amp;hellip;」という場面に頻繁に出くわします。&lt;/p>
&lt;p>自分の場合、Claude CodeやChatGPTでプロジェクト固有のルールを毎回説明し直すのが地味にストレスでした。セッションが切れるたびにリセットされる記憶。これは多くのAIエージェントが抱える根本的な問題です。&lt;/p>
&lt;p>&lt;a href="https://nousresearch.com/" target="_blank" rel="noopener noreferrer">NousResearch&lt;/a>
（Hermesモデルファミリーの開発元）が2026年2月にリリースした&lt;a href="https://github.com/NousResearch/hermes-agent" target="_blank" rel="noopener noreferrer">Hermes Agent&lt;/a>
は、この「エージェントの健忘症」に正面から取り組んだオープンソースプロジェクトです。本記事では、その永続メモリの設計を中心に、何が新しいのかを整理します。&lt;/p></description></item><item><title>Alloy: Rust製EthereumライブラリでのWeb3開発入門</title><link>https://blog.tumf.dev/posts/diary/2026/3/20/alloy-rust-ethereum-library/</link><pubDate>Fri, 20 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/20/alloy-rust-ethereum-library/</guid><description>&lt;p>&lt;a href="https://blog.tumf.dev/tags/rust">Rust&lt;/a>
 でEthereumアプリケーションを開発するなら、&lt;a href="https://github.com/alloy-rs/alloy" target="_blank" rel="noopener noreferrer">Alloy&lt;/a>
 を知っておく必要があります。&lt;/p>
&lt;p>Alloyは、長く使われてきた &lt;code>ethers-rs&lt;/code> の後継ライブラリです。モダンなRustのイディオムを取り入れ、パフォーマンスと型安全性を大幅に向上させました。2024年6月にv0.1が初回リリースされ、2025年5月にv1.0安定版に到達しました。2026年現在では新規&lt;a href="https://blog.tumf.dev/tags/ethereum">Ethereum&lt;/a>
プロジェクトの標準的な選択肢となっています。&lt;/p></description></item><item><title>uv tool list --outdated: 古いCLIツールを棚卸しして更新漏れを減らす</title><link>https://blog.tumf.dev/posts/diary/2026/3/19/uv-tool-list-outdated-toolbox-tech-debt/</link><pubDate>Thu, 19 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/19/uv-tool-list-outdated-toolbox-tech-debt/</guid><description>&lt;p>&lt;code>uv tool list --outdated&lt;/code> を使うと、&lt;code>uv tool install&lt;/code> で入れた CLI のうち、古いものだけを一覧できます。
「uv でツール更新漏れを確認したい」「ローカルや CI に入れた CLI が古くなっていないか見たい」という用途に、そのまま刺さる機能です。&lt;/p>
&lt;p>Python の依存関係には &lt;code>uv lock&lt;/code> や &lt;code>uv sync&lt;/code> がありますが、&lt;strong>個人の道具箱&lt;/strong>として入れた CLI 群は管理の粒度が違います。
プロジェクトの再現性というより、ローカル環境の衛生管理や、CI・Docker イメージ内のツール保守が課題になります。&lt;/p>
&lt;p>以前書いた &lt;a href="https://blog.tumf.dev/posts/diary/2025/1/5/python-uv-subcommands/">uv add/remove/syncの使い方: Pythonパッケージ管理を完全理解&lt;/a>
 では、プロジェクト依存をどう管理するかを整理しました。今回の &lt;code>uv tool list --outdated&lt;/code> はその外側で、&lt;strong>常用 CLI の棚卸し&lt;/strong>を楽にする機能です。&lt;/p>
&lt;p>uv 0.10.10 で入ったこのフラグは、地味ですが確実に溜まる更新漏れを見える化します。CLI を「気分で足すもの」から「継続的に整備する資産」へ変える一歩です。&lt;/p></description></item><item><title>AGENTS.md / CLAUDE.md の先へ：GitAgentが提案するエージェント定義のバージョン管理</title><link>https://blog.tumf.dev/posts/diary/2026/3/18/gitagent-git-native-agent-standard/</link><pubDate>Wed, 18 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/18/gitagent-git-native-agent-standard/</guid><description>&lt;p>Claude Code の &lt;code>CLAUDE.md&lt;/code> や GitHub Copilot の &lt;code>AGENTS.md&lt;/code>——最近のAIコーディングツールは、リポジトリにMarkdownファイルを置いてエージェントの振る舞いを定義する方向に収束しつつあります。&lt;/p>
&lt;p>でも、ファイルが増えてくると困ることがあります。「このエージェント定義、別のフレームワークでも使いたいんだけど」「プロンプトの変更履歴を追いたい」「本番環境と開発環境でエージェントの設定を分けたい」。こういう要望に対して、既存のアプローチはちょっと力不足なんですよね。&lt;/p>
&lt;p>&lt;a href="https://www.gitagent.sh/" target="_blank" rel="noopener noreferrer">GitAgent&lt;/a>
（&lt;a href="https://github.com/open-gitagent/gitagent" target="_blank" rel="noopener noreferrer">GitHub&lt;/a>
）は、この問題に正面から取り組んでいるオープン標準です。「Gitリポジトリそのものをエージェント定義にする」という発想で、バージョン管理・コンプライアンス・フレームワーク間のポータビリティを一気に解決しようとしています。&lt;/p></description></item><item><title>CanIRun.ai: 手持ちGPUでどのLLMが動くか一発でわかるツール</title><link>https://blog.tumf.dev/posts/diary/2026/3/17/canirun-ai-local-llm-gpu-checker/</link><pubDate>Tue, 17 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/17/canirun-ai-local-llm-gpu-checker/</guid><description>&lt;p>「このLLM、自分のGPUで動くのかな？」——ローカルLLMを試すたびにGoogleで「RTX 4070 Llama 3 VRAM」と検索して、Redditのスレッドを読み漁る。そんな経験はないでしょうか。&lt;/p>
&lt;p>&lt;a href="https://www.canirun.ai/" target="_blank" rel="noopener noreferrer">CanIRun.ai&lt;/a>
 は、ブラウザを開くだけで手持ちのハードウェアを自動検出し、各LLMがどの程度の速度で動くかをスコアリングしてくれるWebツールです。Hacker Newsで1位（1,361ポイント）を獲得し、大きな注目を集めました。&lt;/p></description></item><item><title>Lightpanda: AIエージェント時代のヘッドレスブラウザ — Chromeの11倍速・メモリ1/9で動く</title><link>https://blog.tumf.dev/posts/diary/2026/3/16/lightpanda-headless-browser-for-ai-agents/</link><pubDate>Mon, 16 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/16/lightpanda-headless-browser-for-ai-agents/</guid><description>&lt;p>最近、&lt;a href="https://blog.tumf.dev/tags/ai/">AI&lt;/a>
エージェントにWebブラウジング能力を持たせる場面が増えてきました。スクレイピング、フォーム操作、ページの検証——エージェントがブラウザを使うたびにChromeのヘッドレスモードを立ち上げるわけですが、これがまあ重い。1エージェントあたり200MB超のメモリを食うので、同時に10台も走らせるとサーバがヒーヒー言います。&lt;/p>
&lt;p>&lt;a href="https://lightpanda.io/" target="_blank" rel="noopener noreferrer">Lightpanda&lt;/a>
 は、まさにこの問題を解決するために一から設計されたヘッドレスブラウザです。Zig言語で書かれていて、CSSレンダリングやGPU合成を一切省略し、DOMツリーとJavaScript実行だけに特化しています。本記事ではLightpandaの特徴、導入方法、実際の使い方を紹介します。&lt;/p></description></item><item><title>agent-execにイベント通知が来た: ポーリング不要のジョブ完了ワークフロー</title><link>https://blog.tumf.dev/posts/diary/2026/3/15/agent-exec-job-finished-events/</link><pubDate>Sun, 15 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/15/agent-exec-job-finished-events/</guid><description>&lt;p>以前の記事「&lt;a href="https://blog.tumf.dev/posts/diary/2026/2/19/agent-exec-stdout-stderr-separation/">CLIの出力設計を間違えると、AIエージェントは何も読めない&lt;/a>
」で紹介した &lt;a href="https://github.com/tumf/agent-exec" target="_blank" rel="noopener noreferrer">agent-exec&lt;/a>
 に、ずっと欲しかった機能を入れました。&lt;a href="https://blog.tumf.dev/tags/rust/">Rust&lt;/a>
製ジョブランナーに追加したジョブ完了時のイベント通知です。&lt;/p>
&lt;p>これまではジョブの完了を知るには &lt;code>agent-exec wait&lt;/code> か &lt;code>agent-exec status&lt;/code> をポーリングするしかなかったんですが、実際にオーケストレーションパイプラインを組むとポーリングが辛い。間隔が短すぎるとリソースの無駄、長すぎると反応が遅れる。結局「完了したら教えてくれ」が一番素直だよなと思って、Job Finished Events を実装しました。&lt;/p></description></item><item><title>PostgreSQL互換でブランチできる DB、DoltgreSQL がかなり面白い</title><link>https://blog.tumf.dev/posts/diary/2026/3/13/doltgresql-version-controlled-postgresql/</link><pubDate>Fri, 13 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/13/doltgresql-version-controlled-postgresql/</guid><description>&lt;!--
editorial-note:
 狙い: "PostgreSQL ブランチ" "データベース バージョン管理" 等のキーワードで検索流入を取る。
 既存の pgdog / turso / supabase 記事群と内部リンクし、DB 系クラスタを強化する。
 ターゲット読者: PostgreSQL を普段使いしているバックエンド / インフラ系エンジニア。
 DB マイグレーション・ステージング運用に課題を感じている人。
 差別化: 日本語での実践的な DoltgreSQL 解説記事はまだ少ない。
 ベンチマーク数値（5.2x overhead）や正確性（91%）など定量情報を含める。
 内部リンク候補:
 - /posts/diary/2026/02/24/pgdog-rust-tokio-async-benchmark/ (PostgreSQL プロキシ)
 - /posts/diary/2025/12/30/turso-mcp-server-ai-agent-database/ (AIエージェント×DB)
 - /posts/diary/2025/12/24/supabase-migration-complete-guide/ (DB マイグレーション)
 - /posts/diary/2025/1/7/pgbouncer-ha/ (PostgreSQL 運用)
 - /posts/diary/2026/1/10/git-ignore-methods-comparison/ (Git 系)
-->
&lt;p>「DBのスキーマだけじゃなくて、データそのものにも &lt;a href="https://blog.tumf.dev/tags/git/">Git&lt;/a>
 みたいにブランチ切れたら楽なのに」——&lt;a href="https://blog.tumf.dev/tags/postgresql/">PostgreSQL&lt;/a>
 でマイグレーションを運用していると、一度はそう思ったことがあるんじゃないでしょうか。&lt;/p>
&lt;p>&lt;a href="https://github.com/dolthub/doltgresql" target="_blank" rel="noopener noreferrer">DoltgreSQL&lt;/a>
 は、まさにそれを実現するデータベースです。PostgreSQL 互換のワイヤプロトコルを持ちながら、内部では &lt;a href="https://blog.tumf.dev/tags/git/">Git&lt;/a>
 ライクなバージョン管理エンジンが動いていて、SQL だけで &lt;code>branch&lt;/code> / &lt;code>merge&lt;/code> / &lt;code>diff&lt;/code> が全部できます。本記事では、インストールから基本的なブランチ操作まで試した感想をまとめます。&lt;/p></description></item><item><title>Graphitiとリアルタイム知識グラフ: 何を解決し、どこで効くのか</title><link>https://blog.tumf.dev/posts/diary/2026/3/10/graphiti-real-time-knowledge-graph-what-it-solves/</link><pubDate>Tue, 10 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/10/graphiti-real-time-knowledge-graph-what-it-solves/</guid><description>&lt;p>&lt;a href="https://github.com/getzep/graphiti" target="_blank" rel="noopener noreferrer">Graphiti&lt;/a>
 を見ていて面白かったのは、「知識グラフを使う」こと自体より、「更新し続けるデータをどう扱うか」を正面から設計している点でした。&lt;/p>
&lt;p>RAG（Retrieval-Augmented Generation: 検索拡張生成）系のツールはかなり増えましたが、多くは静的な文書集合を前提にしています。そこにユーザーとの会話、状態が変わる業務データ、あとから訂正される事実が入ってくると、だんだん「検索はできるが、今どうなっているかが曖昧」という状態になりがちです。&lt;/p>
&lt;p>本記事では、Graphitiがその問題をどう解こうとしているのかを整理します。あわせて、普通のベクトルRAG（embedding: テキストを数値ベクトルに変換して近い文書を探す方式）と何が違うのか、実際に試す最小コードも含めて見ていきます。&lt;/p></description></item><item><title>Web→Adapter→Tool→Agent: 自己学習型スキルで『再訪を実測で平均98%トークン削減』する</title><link>https://blog.tumf.dev/posts/diary/2026/3/9/web-adapter-tool-agent-architecture/</link><pubDate>Mon, 09 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/9/web-adapter-tool-agent-architecture/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/web-adapter-tool-agent-turn-self-learning-skills-into-98-average-token-reduction-on-revisits-3mi4">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>Webから情報を取る処理を、LLMに毎回「生HTMLを読ませて頑張らせる」形で組むと、だいたい高くて遅くて壊れやすいです。
しかも、同じサイトを何度も読むユースケース（ニュース監視、ドキュメント追跡、価格改定検知など）だと、同じ失敗を何度も繰り返します。&lt;/p>
&lt;p>この手の問題は、気合のスクレイピングテクで解決するというより、「一度うまくいった抽出方法を“道具”として固定化し、次回以降は再利用する」と割り切った方が素直に効きます。
この記事では、Web→Adapter→Tool→Agentという変換パイプラインで、スクレイピングを&lt;strong>学習で道具化&lt;/strong>する設計をまとめます。&lt;/p>
&lt;p>元々の着想は、以前の記事で紹介した &lt;a href="https://blog.tumf.dev/posts/diary/2026/3/1/web2cli-every-website-is-a-unix-command/">web2cli&lt;/a>
（&lt;a href="https://github.com/jb41/web2cli" target="_blank" rel="noopener noreferrer">GitHubリポジトリ&lt;/a>
）です。
あの記事の「Every website is a Unix command」という思想を、エージェント運用（再訪/トークン/ドリフト）に寄せていくと、だいたいこの方向に収束します。&lt;/p>
&lt;p>最近、その延長線として &lt;a href="https://github.com/tumf/self-learning-web-adapter" target="_blank" rel="noopener noreferrer">self-learning-web-adapter&lt;/a>
 という&lt;strong>自己学習型スキル&lt;/strong>（skill: エージェントに渡す手順とツールのパッケージ）を追加しました。
スキル本体は &lt;a href="https://github.com/tumf/self-learning-web-adapter/tree/main/skills/self-learning-web-adapter" target="_blank" rel="noopener noreferrer">skills/self-learning-web-adapter&lt;/a>
 に置いてあります。&lt;/p></description></item><item><title>MEV投資戦略: SearcherとしてMEVを獲得する全体像</title><link>https://blog.tumf.dev/posts/diary/2026/3/8/mev-bot-architecture-design-decisions/</link><pubDate>Sun, 08 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/8/mev-bot-architecture-design-decisions/</guid><description>&lt;p>最近、&lt;a href="https://blog.tumf.dev/tags/ethereum/">Ethereum&lt;/a>
周りを追っていると、&lt;a href="https://ethereum.org/en/developers/docs/mev/" target="_blank" rel="noopener noreferrer">MEV&lt;/a>
（Maximal Extractable Value）という言葉を避けて通れなくなりました。&lt;/p>
&lt;p>MEVは「チェーン上の取引から追加利益を抜く」話なので、投資というより&lt;strong>トレーディング戦略&lt;/strong>に近い領域です。&lt;/p>
&lt;p>自分が最初にMEVを追い始めたとき、「結局どのプレイヤーが、何を根拠に、どこで利益を取っているのか」が整理できずに迷子になりました。&lt;/p>
&lt;p>この記事では、話を追いやすいように、&lt;/p>
&lt;ul>
&lt;li>MEVが何か（まず用語と発生源）&lt;/li>
&lt;li>MEVのプレイヤーと市場構造（誰が儲けて、誰が負担するか）&lt;/li>
&lt;li>「MEVを獲得する」ための投資戦略（資本配分、期待値、勝ち筋、リスク管理）&lt;/li>
&lt;/ul>
&lt;p>だけに絞って、全体像を作ります。&lt;/p>
&lt;p>注意: 本記事は教育目的の解説であり、特定の銘柄・商品・取引の推奨ではありません。MEVは損失や法務・倫理リスクもあります。&lt;/p></description></item><item><title>LLM時代のフェルミ推定は「勘」より「監査可能性」が価値</title><link>https://blog.tumf.dev/posts/diary/2026/3/7/fermi-estimation-auditability-over-guesswork/</link><pubDate>Sat, 07 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/7/fermi-estimation-auditability-over-guesswork/</guid><description>&lt;p>&lt;a href="https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A7%E3%83%AB%E3%83%9F%E6%8E%A8%E5%AE%9A" target="_blank" rel="noopener noreferrer">フェルミ推定&lt;/a>
って、雑に言うと「ざっくり妥当な数字を出す技術」です。
市場規模、工数、必要人員、処理能力みたいな話で、まだ正確なデータが揃っていない時にかなり便利です。&lt;/p>
&lt;p>ただ、LLM（Large Language Model: 大規模言語モデル）にこの手の仕事を任せると、別の問題が出ます。
数字自体はそれっぽく見えても、「何を根拠にその数字になったのか」が残らないと、あとから見直せません。&lt;/p>
&lt;p>そこで、自作スキル &lt;a href="https://github.com/tumf/skills/tree/main/fermi-estimation" target="_blank" rel="noopener noreferrer">fermi-estimation&lt;/a>
 を作りました。
狙いは、フェルミ推定をうまくやることそのものではなく、&lt;strong>推定結果をあとから監査できる形で残すこと&lt;/strong>です。
ここで言う監査可能性とは、あとから見直せる、反論できる、再計算できることです。&lt;/p></description></item><item><title>Agent Skillsに対応した最小のAIエージェントをPythonで書いてみる</title><link>https://blog.tumf.dev/posts/diary/2026/3/6/minimal-agent-skills-python/</link><pubDate>Fri, 06 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/6/minimal-agent-skills-python/</guid><description>&lt;p>&lt;a href="https://www.anthropic.com/" target="_blank" rel="noopener noreferrer">Anthropic&lt;/a>
 の &lt;a href="https://platform.claude.com/docs/ja/agents-and-tools/agent-skills/overview" target="_blank" rel="noopener noreferrer">Agent Skills overview&lt;/a>
 を読んでいて、これは大きなフレームワークから入るより、まず最小構成で動きを見た方が早そうだなと思いました。&lt;/p>
&lt;p>今回は、公式仕様を完全に再現する実装ではなく、Agent Skills の考え方を理解するためのローカル実験として作ります。&lt;/p>
&lt;p>Agent Skills は、ざっくり言うと「エージェントに渡す再利用可能な作業手順」です。毎回長いプロンプトを書く代わりに、よく使う手順をスキル（skill: 再利用できる手順書の単位）として切り出しておくイメージです。&lt;/p>
&lt;p>本記事では、Python だけで動く「最小のスキル対応エージェント」を作ります。前半で「スキルを見つける」「選ぶ」「実行する」という流れをローカルで再現し、後半で実際に LLM（Large Language Model: 大規模言語モデル）へ接続するところまでやります。&lt;/p></description></item><item><title>Eternal TerminalがmacOS+Tailscaleで接続できない（Receiving client idで止まる）ときの切り分け</title><link>https://blog.tumf.dev/posts/diary/2026/3/5/eternalterminal-macos-tailscale-receiving-client-id-timeout/</link><pubDate>Thu, 05 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/5/eternalterminal-macos-tailscale-receiving-client-id-timeout/</guid><description>&lt;p>macOS同士（Apple Silicon）のマシンを&lt;a href="https://tailscale.com/" target="_blank" rel="noopener noreferrer">Tailscale&lt;/a>
でつないでいます。
&lt;a href="https://mistertea.github.io/EternalTerminal/" target="_blank" rel="noopener noreferrer">Eternal Terminal&lt;/a>
（GitHub: &lt;a href="https://github.com/MisterTea/EternalTerminal" target="_blank" rel="noopener noreferrer">MisterTea/EternalTerminal&lt;/a>
）で接続しようとすると、&lt;code>Receiving client id&lt;/code> から進まない沼にハマりました。&lt;/p>
&lt;p>結論から言うと、この記事の時点では&lt;strong>完全解決していません&lt;/strong>。
ただ、観測できた挙動と切り分けの手順を整理すると「どこが壊れていそうか」をかなり狭められます。ムダに時間を溶かさず、次のアクションへ進むための記事です。&lt;/p>
&lt;p>本文中のホスト名とIPはダミー化しています（例: &lt;code>server&lt;/code>, &lt;code>100.64.0.10&lt;/code>）。&lt;/p></description></item><item><title>日本の補助金・助成金を調べる自作スキル「jp-grants」を作った</title><link>https://blog.tumf.dev/posts/diary/2026/3/4/jp-grants-japanese-subsidies-skill/</link><pubDate>Wed, 04 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/4/jp-grants-japanese-subsidies-skill/</guid><description>&lt;p>補助金・助成金って、知ってる人は当たり前に申請していて、知らない人はそもそも存在に気づかない、みたいな情報だと思っています。
一方で、いざ調べ始めるとページが散らばっていたり、年度や公募回で要件が変わったり、PDF（公募要領）に大事なことが書いてあったりで、地味に時間が溶けます。&lt;/p>
&lt;p>そこで「候補を集めて、要点を揃えて、公式リンクに戻れる」くらいの道具が欲しくて、自作スキル &lt;a href="https://github.com/tumf/skills/tree/main/jp-grants" target="_blank" rel="noopener noreferrer">jp-grants&lt;/a>
 を作りました。
LLM（Large Language Model: 大規模言語モデル）に聞くとしても、最終的に公式ページへ着地できないと怖いので、URLと根拠を残す方針です。&lt;/p></description></item><item><title>enject（旧enveil）: AIに.envを覗かせないために『平文をディスクに置かない』という選択</title><link>https://blog.tumf.dev/posts/diary/2026/3/3/enveil-hide-env-secrets/</link><pubDate>Tue, 03 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/3/enveil-hide-env-secrets/</guid><description>&lt;p>&lt;a href="https://blog.tumf.dev/tags/ai/">AI&lt;/a>
コーディングツールが当たり前になってきて、&lt;code>.env&lt;/code>（環境変数ファイル）を&lt;strong>そのまま置く怖さ&lt;/strong>が目に見えるようになりました。&lt;/p>
&lt;p>ファイルが読めるなら、秘密も読めます。ここはAI時代の&lt;a href="https://blog.tumf.dev/tags/security/">セキュリティ&lt;/a>
として、無視しにくい問題だと思います。&lt;/p>
&lt;p>この記事では、&lt;a href="https://github.com/GreatScott/enject" target="_blank" rel="noopener noreferrer">enject&lt;/a>
（旧enveil）を中心に、「AIが読める場所に秘密を置かない」という発想を整理します。&lt;/p>
&lt;p>（補足）プロジェクトは以前 enveil という名前でしたが、現在は enject にリネームされています。&lt;/p>
&lt;p>その上で、&lt;a href="https://dotenvx.com/" target="_blank" rel="noopener noreferrer">dotenvx&lt;/a>
 を比較対象として出し、チーム/CIまで含めた運用で何が変わるかも見ます。&lt;/p></description></item><item><title>AISHでターミナルログのノイズを減らす: PTY実行と要約の分離が効く理由</title><link>https://blog.tumf.dev/posts/diary/2026/3/2/aish-pty-shell-wrapper/</link><pubDate>Mon, 02 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/2/aish-pty-shell-wrapper/</guid><description>&lt;p>ターミナルの出力は、必要な情報があるのに長すぎる。特にテスト失敗やビルドエラーのとき、欲しいのは「どこで落ちたか」と「その前後」だけです。&lt;/p>
&lt;p>そこで試したのが&lt;a href="https://origo-labs.github.io/aish/" target="_blank" rel="noopener noreferrer">AISH公式サイト&lt;/a>
で紹介されているAISH（PTY-first shell wrapper / “signal, not noise”）です。&lt;a href="https://github.com/origo-labs/aish" target="_blank" rel="noopener noreferrer">AISHリポジトリ&lt;/a>
のREADMEを見ると、PTY（擬似端末）でコマンドを実行しつつ、出力を完全保存し、デフォルトは要約だけ出す設計になっています。&lt;/p>
&lt;p>このツールは「AIが読むための出力設計」ではなく、「人間が読むべき場所だけ残す」ための設計です。ログを削らずに残しつつ、読むべき場所だけ短く出す。ここが一番の価値だと思います。&lt;/p></description></item><item><title>web2cli: Every website is a Unix command - ブラウザ自動化の前に「HTTPだけで済む仕事」を片付ける</title><link>https://blog.tumf.dev/posts/diary/2026/3/1/web2cli-every-website-is-a-unix-command/</link><pubDate>Sun, 01 Mar 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/3/1/web2cli-every-website-is-a-unix-command/</guid><description>&lt;p>Webから情報を取る方法って、極端に寄りがちです。&lt;/p>
&lt;ul>
&lt;li>API（Application Programming Interface: 提供元が用意する機械向けの窓口）があるサイトはAPIを叩く&lt;/li>
&lt;li>APIがない/高い/制限がキツいと、ブラウザ自動化（Playwrightなど）に寄る&lt;/li>
&lt;/ul>
&lt;p>でも、ブラウザ自動化は重い。
特にAIエージェント（AI agent: LLMが外部ツールを使って作業する仕組み）に組み込むと、遅い・高い・壊れやすいの三拍子になりがちです。&lt;/p>
&lt;p>そんな中で見つけたのが、&lt;a href="https://github.com/jb41/web2cli" target="_blank" rel="noopener noreferrer">web2cli&lt;/a>
です。
コンセプトはREADMEに書かれている通りで、かなり強い。&lt;/p>
&lt;p>&amp;ldquo;Every website is a Unix command.&amp;rdquo;&lt;/p>
&lt;p>ここで言うUnixコマンド（Unix command: 標準入力/標準出力でつなげられる、いわゆるCLIコマンドの作法）としてWebを扱えるようにする、という話です。&lt;/p></description></item><item><title>ACP実装ガイド: エディタとコーディングエージェントの共通語</title><link>https://blog.tumf.dev/posts/diary/2026/2/28/agent-client-protocol-introduction/</link><pubDate>Sat, 28 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/28/agent-client-protocol-introduction/</guid><description>&lt;p>&lt;a href="https://agentclientprotocol.com/" target="_blank" rel="noopener noreferrer">Agent Client Protocol&lt;/a>
（ACP）は、コードエディタ/IDEとコーディングエージェントの通信を標準化するプロトコルです。最近はAIエージェントの選択肢が増えましたが、実際の連携は各エディタの個別実装に依存しがちです。本記事では、エディタ開発者がすぐに統合を始められる粒度で、仕様の要点と実装の入口をまとめます。仕様の出典は&lt;a href="https://agentclientprotocol.com/get-started/introduction" target="_blank" rel="noopener noreferrer">公式ドキュメント&lt;/a>
と&lt;a href="https://github.com/agentclientprotocol/agent-client-protocol" target="_blank" rel="noopener noreferrer">GitHubのリポジトリ&lt;/a>
です。&lt;/p>
&lt;p>結論だけ言うと、ACPは「エディタとエージェントの間に共通語を作る」ための仕組みです。結果として、&lt;a href="https://blog.tumf.dev/tags/ai/">AI&lt;/a>
や&lt;a href="https://blog.tumf.dev/tags/llm/">LLM&lt;/a>
エージェントの乗り換えや、異なるエディタ間での互換性が取りやすくなります。&lt;/p></description></item><item><title>OpenFangのHands: チャットを待たずに働くエージェントの設計</title><link>https://blog.tumf.dev/posts/diary/2026/2/27/openfang-hands-autonomous-agent-design/</link><pubDate>Fri, 27 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/27/openfang-hands-autonomous-agent-design/</guid><description>&lt;p>先日、&lt;a href="https://www.openfang.sh/" target="_blank" rel="noopener noreferrer">OpenFang&lt;/a>
というオープンソースのAgent Operating Systemを見つけました。「Agent OS」という言葉自体は目新しくないのですが、OpenFangの設計には「Hands（ハンズ）」という独特のコンセプトがあります。&lt;/p>
&lt;p>従来のAIエージェントは「ユーザーがメッセージを送るまで待機する」のが基本ですが、Handsは「スケジュールで自律的に動作し、結果をダッシュボードに報告する」という設計です。この違いは小さく見えて、実は運用上の大きな転換点だと思います。&lt;/p>
&lt;p>本記事では、OpenFangのHandsという設計思想を、既存のエージェントフレームワーク（&lt;a href="https://openclaw.ai/" target="_blank" rel="noopener noreferrer">OpenClaw&lt;/a>
、CrewAI、LangGraph等）との比較を交えながら解説します。&lt;/p></description></item><item><title>ERC-8004 + ERC-8128 = SIWA: AIエージェント認証スタックの2層構造を解剖する</title><link>https://blog.tumf.dev/posts/diary/2026/2/26/erc8128-erc8004-agent-auth-stack/</link><pubDate>Thu, 26 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/26/erc8128-erc8004-agent-auth-stack/</guid><description>&lt;p>&lt;a href="https://blog.tumf.dev/posts/diary/2026/2/17/erc8004-trustless-agents-trust-design/">前回の記事&lt;/a>
で、&lt;a href="https://eips.ethereum.org/EIPS/eip-8004" target="_blank" rel="noopener noreferrer">ERC-8004&lt;/a>
（Trustless Agents）がAIエージェントの「信頼の発見」をどう解決するかを見ました。Identity Registry、Reputation Registry、Validation Registryの3層で「このエージェントを信頼していいか」を判断できる、という話でした。&lt;/p>
&lt;p>ただ、読んでいて気になっていた問題が一つ残っていました。「信頼できるエージェントだとわかった。でも、届いたHTTPリクエストが本当にそのエージェントから来たものかどうか、どうやって確認するの？」という問いです。&lt;/p>
&lt;p>&lt;a href="https://erc8128.org/" target="_blank" rel="noopener noreferrer">ERC-8128&lt;/a>
（Signed HTTP Requests with Ethereum）は、その問いへの答えです。2026年1月に公開されたドラフトで、EthereumアカウントでHTTPリクエストに署名する標準を定義しています。&lt;/p></description></item><item><title>OpenClawのデバイス認証を読み解く: nonce署名・トークンローテーション・5分タイムアウトの設計意図</title><link>https://blog.tumf.dev/posts/diary/2026/2/25/openclaw-pairing-protocol-design/</link><pubDate>Wed, 25 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/25/openclaw-pairing-protocol-design/</guid><description>&lt;p>&lt;a href="https://openclaw.ai/" target="_blank" rel="noopener noreferrer">OpenClaw&lt;/a>
を初めてセットアップしたとき、ちょっとした違和感を覚えました。通常のWebサービスなら当たり前にある「パスワード登録」や「アカウント作成」がないんです。&lt;/p>
&lt;p>「認証どうなってるんだ?」と気になってドキュメントを読み始めたら、Dashboard UIとGatewayのペアリング機構が思いのほか面白い設計になっていました。Challenge-Response認証、デバイストークンのローテーション、5分間のタイムアウトなど、細かい設計判断が積み重なっていて、「ローカル優先だけどセキュアに」という思想が一貫しています。&lt;/p>
&lt;p>本記事では、OpenClawのGateway Protocolを読み解きながら、これらの設計がどう組み合わさって「信頼」を構築しているかを解説します。&lt;/p></description></item><item><title>Tokioランタイムがデータベースプロキシを変える: PgDogのベンチマークから見るRust非同期I/Oの実力</title><link>https://blog.tumf.dev/posts/diary/2026/2/24/pgdog-rust-tokio-async-benchmark/</link><pubDate>Tue, 24 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/24/pgdog-rust-tokio-async-benchmark/</guid><description>&lt;p>PostgreSQLのコネクションプーラーとして長年使われてきた&lt;a href="https://www.pgbouncer.org/" target="_blank" rel="noopener noreferrer">PgBouncer&lt;/a>
。しかし、50接続を超えると性能が頭打ちになる問題をご存知でしょうか。&lt;/p>
&lt;p>この課題を解決するために登場したのが、Rust製の新しいデータベースプロキシ&lt;a href="https://pgdog.dev/" target="_blank" rel="noopener noreferrer">PgDog&lt;/a>
です。PgBouncerと比較して、50接続以上の環境で約10%高速に動作します。&lt;/p>
&lt;p>本記事では、PgDogの公式ベンチマーク結果を元に、Rust/Tokioの非同期I/Oアーキテクチャがデータベースプロキシにもたらす性能向上を解説します。&lt;/p></description></item><item><title>セマンティックエントロピー入門: LLMが「自信なさげ」な回答を数値化する仕組み</title><link>https://blog.tumf.dev/posts/diary/2026/2/23/semantic-entropy-llm-uncertainty/</link><pubDate>Mon, 23 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/23/semantic-entropy-llm-uncertainty/</guid><description>&lt;p>「GPT-4に質問したら、なんか自信なさそうな回答が返ってきた」——そんな経験はありませんか？&lt;/p>
&lt;p>実は、LLMの「自信のなさ」は数値化できます。それを可能にするのが &lt;strong>セマンティックエントロピー&lt;/strong>（Semantic Entropy）という技術です。&lt;/p></description></item><item><title>AIエージェントのメモリは「覚える」だけでは足りない: Mengramが実装した手順進化の仕組み</title><link>https://blog.tumf.dev/posts/diary/2026/2/22/mengram-procedural-memory-evolution/</link><pubDate>Sun, 22 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/22/mengram-procedural-memory-evolution/</guid><description>&lt;p>&lt;a href="https://blog.tumf.dev/tags/ai/">AI&lt;/a>
エージェントに「前回のデプロイ手順を覚えておいて」と頼んでも、次回また同じ失敗を繰り返す——そんな経験はありませんか？&lt;/p>
&lt;p>従来のAIメモリツールは「事実を記憶する」ことに特化していますが、&lt;a href="https://mengram.io/" target="_blank" rel="noopener noreferrer">Mengram&lt;/a>
は一歩進んで「失敗から学習して手順を自動進化させる」仕組みを実装しました。本記事では、Mengramの3層メモリ設計と、他のメモリツール（Mem0、Letta、Zep）との違いを解説します。&lt;/p></description></item><item><title>AIエージェント時代のHITL設計: EIP-7702で実現する都度承認と強制ルールの二重ガード</title><link>https://blog.tumf.dev/posts/diary/2026/2/21/eip7702-hitl-double-guard/</link><pubDate>Sat, 21 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/21/eip7702-hitl-double-guard/</guid><description>&lt;p>&lt;a href="https://blog.tumf.dev/tags/ai/">AIエージェント&lt;/a>
がトランザクションを組み立てる時代、一番怖いのは「変なtxを作られること」です。&lt;/p>
&lt;p>説明文は正しそうに見えるのに、実際の実行内容が全く違う。こういう事故を前提に設計する必要があります。&lt;/p>
&lt;p>本記事の結論は、&lt;strong>AI時代のHITLは『都度承認 + delegate強制ルール』の二重ガードで設計する&lt;/strong>です。&lt;/p></description></item><item><title>ZeroClawのtrait駆動設計: AIエージェントで「swap anything」を実現する方法</title><link>https://blog.tumf.dev/posts/diary/2026/2/20/zeroclaw-trait-driven-design/</link><pubDate>Fri, 20 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/20/zeroclaw-trait-driven-design/</guid><description>&lt;p>AIエージェントを本番運用する際、「LLMプロバイダーを切り替えたい」「チャットツールを変更したい」といった要求は頻繁に発生します。しかし、多くのフレームワークでは、こうした変更にコード修正が必要です。&lt;/p>
&lt;p>&lt;a href="https://github.com/zeroclaw-labs/zeroclaw" target="_blank" rel="noopener noreferrer">ZeroClaw&lt;/a>
は、この問題を「trait駆動設計」で解決しています。設定ファイル1行の変更だけで、LLMプロバイダー、チャットツール、メモリバックエンド、実行環境を切り替えられます。本記事では、Rustの「trait」という仕組みを使った、この柔軟なアーキテクチャを解説します。&lt;/p></description></item><item><title>CLIの出力設計を間違えると、AIエージェントは何も読めない: agent-execが採用した分離戦略</title><link>https://blog.tumf.dev/posts/diary/2026/2/19/agent-exec-stdout-stderr-separation/</link><pubDate>Thu, 19 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/19/agent-exec-stdout-stderr-separation/</guid><description>&lt;p>&lt;a href="https://blog.tumf.dev/tags/ai/">AIエージェント&lt;/a>
に長時間コマンドを実行させたい。でも、既存のCLIツールは「人間が端末で見る」前提で設計されているため、エージェントが出力をパースできません。&lt;/p>
&lt;p>原因は単純です。多くのCLIが「結果」と「ログ」を標準出力（stdout）に混ぜて出力するからです。人間なら目で見分けられますが、エージェントには無理です。&lt;/p>
&lt;p>&lt;a href="https://github.com/tumf/agent-exec" target="_blank" rel="noopener noreferrer">agent-exec&lt;/a>
は、この問題を「stdout = JSON only、stderr = ログ」という厳格な分離で解決した&lt;a href="https://www.rust-lang.org/" target="_blank" rel="noopener noreferrer">Rust&lt;/a>
製ジョブランナーです。本記事では、なぜこの設計が重要なのか、どう実装されているのかを解説します。&lt;/p></description></item><item><title>AIエージェントの記憶と人格を分離する: Memory as Documentationの階層設計</title><link>https://blog.tumf.dev/posts/diary/2026/2/18/openclawd-memory-as-documentation/</link><pubDate>Wed, 18 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/18/openclawd-memory-as-documentation/</guid><description>&lt;p>&lt;a href="https://openclaw.ai/" target="_blank" rel="noopener noreferrer">OpenClaw&lt;/a>
 のワークスペースには &lt;code>SOUL.md&lt;/code>、&lt;code>USER.md&lt;/code>、&lt;code>MEMORY.md&lt;/code>、&lt;code>AGENTS.md&lt;/code>、&lt;code>TOOLS.md&lt;/code> など複数の設定ファイルがあります。それぞれ何を書くべきか、どう使い分けるかを整理します。&lt;/p></description></item><item><title>AIエージェントを雇う時代の信頼設計: ERC-8004の3つのレジストリが担う役割</title><link>https://blog.tumf.dev/posts/diary/2026/2/17/erc8004-trustless-agents-trust-design/</link><pubDate>Tue, 17 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/17/erc8004-trustless-agents-trust-design/</guid><description>&lt;p>企業がAIエージェントを「雇う」時代が、もうすぐ来ます。&lt;/p>
&lt;p>すでに一部の企業では、カスタマーサポート、コード生成、データ分析といったタスクをAIエージェントに任せ始めています。人間の従業員と同じように、エージェントに仕事を発注し、成果物を受け取り、報酬を支払う。そういうワークフローが現実になりつつあります。&lt;/p>
&lt;p>ただ、ここで問題が出てきます。「このAIエージェントに仕事を頼んでいいのか？」——そう思ったとき、あなたは何を確認しますか？&lt;/p>
&lt;p>人間なら履歴書、面接、リファレンスチェックがあります。でもAIエージェントには、今のところそういう仕組みがありません。&lt;a href="https://eips.ethereum.org/EIPS/eip-8004" target="_blank" rel="noopener noreferrer">ERC-8004&lt;/a>
（Trustless Agents）は、この問いに「ブロックチェーンで解決しよう」と提案した規格です。2025年8月にドラフトが公開され、2026年1月に&lt;a href="https://blog.tumf.dev/tags/ethereum/">Ethereum&lt;/a>
メインネットへのデプロイが始まりました。&lt;/p></description></item><item><title>X.com API従量課金時代のCLI設計: xcom-rsが実装したコストガードレールと冪等性</title><link>https://blog.tumf.dev/posts/diary/2026/2/16/xcom-rs-pay-per-use-cli-design/</link><pubDate>Mon, 16 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/16/xcom-rs-pay-per-use-cli-design/</guid><description>&lt;p>2026年2月6日、X.com（旧Twitter）が&lt;a href="https://developer.x.com/" target="_blank" rel="noopener noreferrer">X API&lt;/a>
の新しい従量課金モデル（Pay-Per-Use）を発表しました。これまでの月額200ドル・5,000ドルの固定プランから、API呼び出しごとに課金されるクレジット制に移行します。&lt;/p>
&lt;p>この変更により、&lt;a href="https://blog.tumf.dev/tags/ai/">AIエージェント&lt;/a>
にX.com APIを操作させる際の設計要件が大きく変わりました。「何度実行しても安全」だった無料APIと違い、「1回の誤実行が課金につながる」有料APIでは、CLIツールに新しい防御機構が必要です。&lt;/p>
&lt;p>本記事では、私が開発した&lt;a href="https://github.com/tumf/xcom-rs" target="_blank" rel="noopener noreferrer">xcom-rs&lt;/a>
というRust製X.com API CLIツールを題材に、従量課金時代のCLI設計で実装すべき3つの防御策（コストガードレール、冪等性、リスクメタデータ）を解説します。&lt;/p></description></item><item><title>Greenlight: App Store提出前に拒否リスクをローカルで検知するCLI</title><link>https://blog.tumf.dev/posts/diary/2026/2/15/greenlight-app-store-compliance-scanner/</link><pubDate>Sun, 15 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/15/greenlight-app-store-compliance-scanner/</guid><description>&lt;p>App Storeの審査で拒否されると、修正→再提出→再審査のサイクルで数日から数週間のロスが発生します。プライバシーポリシーの不備、必須APIの説明不足、禁止されたAPIの使用など、拒否理由は多岐にわたり、事前に気づくのは困難です。&lt;/p>
&lt;p>&lt;a href="https://github.com/RevylAI/greenlight" target="_blank" rel="noopener noreferrer">Greenlight&lt;/a>
は、提出前にこれらの拒否リスクをローカル環境で検知するオープンソースのCLIツールです。ソースコード、プライバシーマニフェスト、IPAバイナリ、App Store Connectのメタデータを解析し、Appleの審査ガイドラインに違反する可能性のある問題を事前に発見します。&lt;/p></description></item><item><title>goplaces: AIエージェント用 Google Map CLI</title><link>https://blog.tumf.dev/posts/diary/2026/2/14/goplaces-ai-agent-location-integration/</link><pubDate>Sat, 14 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/14/goplaces-ai-agent-location-integration/</guid><description>&lt;p>「近くのカフェを探して」——&lt;a href="https://blog.tumf.dev/tags/ai/">AIエージェント&lt;/a>
にこう頼んだとき、エージェントがやるべきことは意外と単純です。&lt;/p>
&lt;p>1つは「検索したい意図」（例: coffee/ramen）。もう1つは「検索の起点になる位置」です。後者はOSの位置情報やアプリ側の設定、あるいはユーザー入力で用意して、エージェントに渡します（goplacesが勝手に現在地を特定するわけではありません）。&lt;/p>
&lt;p>設定次第では、&lt;a href="https://claude.ai/" target="_blank" rel="noopener noreferrer">Claude&lt;/a>
や&lt;a href="https://opencode.ai/" target="_blank" rel="noopener noreferrer">OpenCode&lt;/a>
、&lt;a href="https://developers.openai.com/codex/" target="_blank" rel="noopener noreferrer">Codex&lt;/a>
のようなエージェントがローカルでシェルコマンドを実行できます。つまり、位置を入力として受け取り、外部APIで検索/経路案内を返すCLIが1つあれば、それだけで「位置情報スキル」を組み込めます。&lt;/p>
&lt;p>そこで今回は、Google Places/Routesを叩けるCLIである&lt;a href="https://goplaces.sh/" target="_blank" rel="noopener noreferrer">goplaces&lt;/a>
を使って、この部分を安定して回すための実装パターンをまとめます。CLIを「エージェントが呼び出すプロトコル」として設計する観点は、先に「&lt;a href="https://blog.tumf.dev/posts/diary/2026/2/6/agentic-cli-design-principles/">Agentic CLI Design: CLIをAIエージェント向けプロトコルとして設計する7つの原則&lt;/a>
」で整理しました。本記事はその具体例です。&lt;/p></description></item><item><title>RAGが苦手な「状態の蓄積」をRowboatはどう解決しているか：エンティティ解決とバッチ処理の設計</title><link>https://blog.tumf.dev/posts/diary/2026/2/13/rowboat-entity-resolution-batch-processing/</link><pubDate>Fri, 13 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/13/rowboat-entity-resolution-batch-processing/</guid><description>&lt;p>AIエージェントに「記憶」を持たせる方法として、RAG（Retrieval-Augmented Generation）が広く使われています。しかし、RAGには「毎回検索してコンテキストを再構築する」という根本的な制約があります。&lt;/p>
&lt;p>ここでのRAGは、外部のデータ（文書・ログなど）を検索して、LLM（Large Language Model: 大規模言語モデル）に渡す仕組みです。
一方で「状態の蓄積（前回の決定が、今回どう更新されたか）」は苦手になりやすいです。&lt;/p>
&lt;p>&lt;a href="https://github.com/rowboatlabs/rowboat" target="_blank" rel="noopener noreferrer">Rowboat&lt;/a>
は、この問題を「継続的にナレッジグラフ（知識をノードとリンクで表す構造）を更新し、状態を蓄積する」アプローチで解決しようとするオープンソース（Apache-2.0）のローカルファーストAIコワーカーです。
&lt;a href="https://www.ycombinator.com/" target="_blank" rel="noopener noreferrer">Y Combinator&lt;/a>
のS24出身のチームが開発しており、メール（&lt;a href="https://www.google.com/gmail/" target="_blank" rel="noopener noreferrer">Gmail&lt;/a>
）や会議メモ（&lt;a href="https://granola.so/" target="_blank" rel="noopener noreferrer">Granola&lt;/a>
、&lt;a href="https://fireflies.ai/" target="_blank" rel="noopener noreferrer">Fireflies&lt;/a>
）から情報を抽出します。
抽出した情報は、&lt;a href="https://obsidian.md/" target="_blank" rel="noopener noreferrer">Obsidian&lt;/a>
互換（ObsidianはMarkdownベースのノートアプリ）のMarkdownファイルとして保存され、リンク（バックリンク: &lt;code>[[...]]&lt;/code> でノート同士を参照する仕組み）でつながります。
ローカルファースト（データをクラウドではなく端末内に置く設計）なので、内容を自分で確認・編集できるのが売りです。
本記事では、Rowboatの設計思想、特にエンティティ解決（Entity Resolution: 表記ゆれや文脈をまたいで同一の人物/組織を統合する処理）とバッチ処理の実装を掘り下げます。&lt;/p></description></item><item><title>エージェント時代の"sudoers"を作る：Claude Code Damage Controlの設計を読む</title><link>https://blog.tumf.dev/posts/diary/2026/2/12/claude-code-damage-control-pretooluse-hooks/</link><pubDate>Thu, 12 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/12/claude-code-damage-control-pretooluse-hooks/</guid><description>&lt;p>AIエージェントに権限を渡す前に、何を守るべきか。&lt;/p>
&lt;p>&lt;a href="https://code.claude.com/" target="_blank" rel="noopener noreferrer">Claude Code&lt;/a>
のようなAIコーディングアシスタントは、ファイルの編集やシェルコマンドの実行を自律的に行います。便利な反面、&lt;code>rm -rf /&lt;/code>のような破壊的な操作や、機密ファイルへの意図しないアクセスが現実のリスクになっています。&lt;/p>
&lt;p>&lt;a href="https://github.com/disler/claude-code-damage-control" target="_blank" rel="noopener noreferrer">Claude Code Damage Control&lt;/a>
は、こうした事故を防ぐための「強制ガードレール」です。PreToolUseフック（ツール実行前に割り込める仕組み）を使い、危険なコマンドやパス操作を検知して、実行前にブロックまたは確認ダイアログへ誘導します。&lt;/p>
&lt;p>感覚としては、エージェント時代のsudoers（&lt;code>sudo&lt;/code>の許可ルール定義）を作る、に近いです。&lt;/p></description></item><item><title>Agentic CLI Designを実装する: slack-rsで学ぶ7原則の具体化</title><link>https://blog.tumf.dev/posts/diary/2026/2/11/slack-rs-agentic-cli-implementation/</link><pubDate>Wed, 11 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/11/slack-rs-agentic-cli-implementation/</guid><description>&lt;p>先日、「&lt;a href="https://blog.tumf.dev/posts/diary/2026/2/6/agentic-cli-design-principles/">Agentic CLI Design: CLIをAIエージェント向けプロトコルとして設計する7つの原則&lt;/a>
」という記事で、&lt;a href="https://blog.tumf.dev/tags/ai/">AIエージェント&lt;/a>
が安全に呼び出せるCLIの設計原則を提案しました。&lt;/p>
&lt;p>ただ、原則だけ読んでも「実際どう実装するの?」という疑問が残ります。そこで今回は、自分が開発した&lt;a href="https://github.com/tumf/slack-rs" target="_blank" rel="noopener noreferrer">slack-rs&lt;/a>
というSlack CLIツールを題材に、7つの原則がどう具体的なコードに落とし込まれているかを解説します。&lt;/p></description></item><item><title>Claude CodeでObsidianを高速検索: qmd MCPサーバーの設定と活用</title><link>https://blog.tumf.dev/posts/diary/2026/2/10/qmd-obsidian-claude-code-mcp/</link><pubDate>Tue, 10 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/10/qmd-obsidian-claude-code-mcp/</guid><description>&lt;p>&lt;a href="https://obsidian.md/" target="_blank" rel="noopener noreferrer">Obsidian&lt;/a>
に蓄積した数百、数千のメモを、&lt;a href="https://claude.ai/claude-code" target="_blank" rel="noopener noreferrer">Claude Code&lt;/a>
から自然言語で検索できたら便利だと思いませんか？&lt;/p>
&lt;p>&lt;a href="https://github.com/tobi/qmd" target="_blank" rel="noopener noreferrer">qmd&lt;/a>
（Query Markup Documents）は、&lt;a href="https://www.shopify.com/" target="_blank" rel="noopener noreferrer">Shopify&lt;/a>
 CEO Tobi Lütkeが個人開発したローカルRAG検索エンジンです。サンドボックス実行ツール&lt;a href="https://github.com/binpash/try" target="_blank" rel="noopener noreferrer">try&lt;/a>
の作者でもあります。BM25全文検索、ベクター検索、LLMリランキングの3層構成で、Markdownノート・議事録・ドキュメントを高精度に検索できます。&lt;/p>
&lt;p>本記事では、qmdを&lt;a href="https://blog.tumf.dev/tags/mcp/">Model Context Protocol&lt;/a>
（MCP）サーバーとして設定し、Claude Codeから「Obsidianのメモを検索する」ワークフローを構築する手順を解説します。&lt;/p>
&lt;p>MCP Server の設定パターンを横展開したい場合は、&lt;a href="https://blog.tumf.dev/posts/diary/2025/12/9/claude-code-google-analytics-mcp/">Claude Code で GA4 にアクセスする - Google Analytics MCP Server の活用&lt;/a>
 や &lt;a href="https://blog.tumf.dev/posts/diary/2025/3/13/local-grafana-loki-mcp-cursor/">Grafana Loki MCP Server設定ガイド: CursorでログをAI分析する&lt;/a>
 も合わせて読むと、検索・分析・ログ監視の違いが比較しやすいです。&lt;/p></description></item><item><title>PLP: プロンプトをデプロイせずに差し替える標準仕様</title><link>https://blog.tumf.dev/posts/diary/2026/2/9/plp-prompt-registry-no-deploy-swap/</link><pubDate>Mon, 09 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/9/plp-prompt-registry-no-deploy-swap/</guid><description>&lt;p>LLM（Large Language Model、大規模言語モデル）アプリケーションを本番運用していると、プロンプトの管理が意外と厄介です。「プロンプトを1行変えるだけなのに、フルデプロイが必要」「ドメイン専門家がプロンプトを直接編集できない」「どのバージョンがどの結果を出したか追跡できない」——こうした課題に対して、&lt;a href="https://github.com/GoReal-AI/plp" target="_blank" rel="noopener noreferrer">Prompt Library Protocol&lt;/a>
（PLP）という標準仕様が登場しました。&lt;/p>
&lt;p>本記事では、PLPが提案する「Prompt Registry」（プロンプトを一元管理し、APIで配布する仕組み）という考え方と、その設計思想を解説します。&lt;/p></description></item><item><title>OpenClawハートビート: 通知をスパムにしない常時稼働エージェント設計</title><link>https://blog.tumf.dev/posts/diary/2026/2/8/openclaw-heartbeat-os-design/</link><pubDate>Sun, 08 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/8/openclaw-heartbeat-os-design/</guid><description>&lt;p>&lt;a href="https://openclaw.ai/" target="_blank" rel="noopener noreferrer">OpenClaw&lt;/a>
は、&lt;a href="https://github.com/openclaw/openclaw" target="_blank" rel="noopener noreferrer">GitHubリポジトリ&lt;/a>
を中心に急速に注目を集めている常時稼働型のAIアシスタントです（2026-02-08時点で約15万スター）。&lt;/p>
&lt;p>&lt;a href="https://www.whatsapp.com/" target="_blank" rel="noopener noreferrer">WhatsApp&lt;/a>
、&lt;a href="https://telegram.org/" target="_blank" rel="noopener noreferrer">Telegram&lt;/a>
、&lt;a href="https://slack.com/" target="_blank" rel="noopener noreferrer">Slack&lt;/a>
など複数のチャネルで動作できますが、個人的に「常時稼働を現実にするための設計が入ってる」と感じたのがハートビート機能です。&lt;/p>
&lt;p>本記事では、OpenClawのハートビート機能を、運用上の実用性（通知の出し方、文脈の分け方、コストの抑え方）に寄せて解説します。&lt;/p></description></item><item><title>リモートtmuxでコピーできない原因はmoshだった件</title><link>https://blog.tumf.dev/posts/diary/2026/2/7/mosh-osc52-clipboard-issue/</link><pubDate>Sat, 07 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/7/mosh-osc52-clipboard-issue/</guid><description>&lt;p>先日、リモートサーバの&lt;a href="https://blog.tumf.dev/tags/tmux/">tmux&lt;/a>
セッションでコピーしたテキストが、Mac側のクリップボードに反映されない問題に遭遇しました。&lt;/p>
&lt;p>tmux側の設定は正しいはずなのに、なぜかコピーが効かない。&lt;/p>
&lt;p>結論から言うと、原因は &lt;a href="https://mosh.org/" target="_blank" rel="noopener noreferrer">mosh&lt;/a>
 でした。&lt;/p>
&lt;p>本記事では、mosh経由でOSC 52クリップボード連携が不安定になる理由と、実際に検証した結果、そして実用的な対策をまとめます。&lt;/p></description></item><item><title>Agentic CLI Design: CLIをAIエージェント向けプロトコルとして設計する7つの原則</title><link>https://blog.tumf.dev/posts/diary/2026/2/6/agentic-cli-design-principles/</link><pubDate>Fri, 06 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/6/agentic-cli-design-principles/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/agentic-cli-design-7-principles-for-designing-cli-as-a-protocol-for-ai-agents-2c10">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>CLIツールは長年、人間が端末で操作するためのインターフェースとして設計されてきました。しかし、&lt;a href="https://blog.tumf.dev/tags/llm/">LLM&lt;/a>
（大規模言語モデル）や&lt;a href="https://blog.tumf.dev/tags/ai/">AIエージェント&lt;/a>
（自律的にツールを呼び出してタスクを進めるプログラム）が普及した今、CLIには新しい役割が求められています。それは「エージェントが安全・確実・反復可能に呼び出せるプロトコル/API」としての設計です。&lt;/p>
&lt;p>自分も最近、エージェントにCLIを回させる機会が増えました。人間相手なら気にならない「確認プロンプトで止まる」「ログがstdoutに混ざってパースできない」「同じ操作を再実行して事故る」が、エージェント相手だと普通に起きます。&lt;/p>
&lt;p>本記事では、私が提唱する「Agentic CLI Design」という設計概論をまとめます。CLIを「人間が操作するUI」から「エージェントが呼び出すプロトコル」へと再定義し、失敗前提・再実行前提・非対話前提で成立させるための7つの設計原則です。&lt;/p></description></item><item><title>シングルバイナリで完結するGit hooks: pre-commitからprekへの移行メモ</title><link>https://blog.tumf.dev/posts/diary/2026/2/5/prek-portable-git-hooks-manager/</link><pubDate>Thu, 05 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/5/prek-portable-git-hooks-manager/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/git-hooks-completed-with-a-single-binary-migration-notes-from-pre-commit-to-prek-59b1">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>&lt;a href="https://pre-commit.com/" target="_blank" rel="noopener noreferrer">pre-commit&lt;/a>
を使っていて「Pythonプロジェクトじゃないのに、なぜPythonが必要なんだ」と思ったことはありませんか？&lt;/p>
&lt;p>&lt;a href="https://prek.j178.dev/" target="_blank" rel="noopener noreferrer">prek&lt;/a>
は、pre-commitをRustで再実装したGit hooks管理ツールです。既存の&lt;code>.pre-commit-config.yaml&lt;/code>をそのまま使えて、Pythonランタイム不要、シングルバイナリで動作します。本記事では、prekの特徴と移行手順、そして「速さ」より重要な「ポータビリティ」について書きます。&lt;/p></description></item><item><title>cron・anacron・systemd timer: Linuxタスクスケジューラ3種の使い分け基準</title><link>https://blog.tumf.dev/posts/diary/2026/2/4/linux-task-scheduler-comparison/</link><pubDate>Wed, 04 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/4/linux-task-scheduler-comparison/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/cron-anacron-and-systemd-timer-guidelines-for-choosing-between-three-linux-task-schedulers-g7o">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>「定期的にバックアップを実行したい」「深夜にログをローテーションしたい」——Linuxでタスクを自動実行する方法として、&lt;a href="https://man7.org/linux/man-pages/man8/cron.8.html" target="_blank" rel="noopener noreferrer">cron&lt;/a>
、&lt;a href="https://man7.org/linux/man-pages/man8/anacron.8.html" target="_blank" rel="noopener noreferrer">anacron&lt;/a>
、&lt;a href="https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html" target="_blank" rel="noopener noreferrer">systemd timer&lt;/a>
 の3つが存在します。しかし、「どれを使えばいいのか」と迷う人は多いのではないでしょうか。&lt;/p>
&lt;p>本記事では、これら3つのスケジューラの特性と適材適所を整理し、「結局どれを選ぶべきか」の判断基準を提供します。&lt;/p></description></item><item><title>Supabaseのコストが気になったらPocketBase: $4 VPSで動くBaaSの選択基準</title><link>https://blog.tumf.dev/posts/diary/2026/2/3/pocketbase-vs-supabase-cost-comparison/</link><pubDate>Tue, 03 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/3/pocketbase-vs-supabase-cost-comparison/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/if-youre-concerned-about-supabase-costs-consider-pocketbase-criteria-for-choosing-a-baas-running-4me7">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>&lt;a href="https://supabase.com/" target="_blank" rel="noopener noreferrer">Supabase&lt;/a>
は、PostgreSQLを中心に「欲しい機能がだいたい揃ってる」優れたBaaSです。一方で、プロダクトが伸びる前段の個人開発やMVPだと「まず固定費を抑えたい」「リソース使用量が読めない」といった理由で、コストが気になる場面もあります。関連記事は &lt;a href="https://blog.tumf.dev/tags/baas/">baas&lt;/a>
 と &lt;a href="https://blog.tumf.dev/tags/supabase/">supabase&lt;/a>
 にまとめています。&lt;/p>
&lt;p>自分は &lt;a href="https://blog.tumf.dev/posts/diary/2026/1/31/nandemo-kaisetsu-movie-generator/">なんでも解説動画ジェネレーター&lt;/a>
 で、ジョブキュー管理のために &lt;a href="https://pocketbase.io/" target="_blank" rel="noopener noreferrer">PocketBase&lt;/a>
 を採用しました。理由は単純で、要件がそこまで複雑ではなく、運用コストを最小にしたかったからです。&lt;/p>
&lt;p>本記事では、PocketBaseを「Supabaseの代替」として雑に推すのではなく、PocketBaseを選ぶべき条件（そして選ぶべきでない条件）を整理します。どちらも素晴らしいサービスで、勝ち筋は要件次第です。&lt;/p></description></item><item><title>Googleのsite:検索をやめて: 静的サイトにPagefindを導入</title><link>https://blog.tumf.dev/posts/diary/2026/2/2/google-site-search-to-pagefind-migration/</link><pubDate>Mon, 02 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/2/google-site-search-to-pagefind-migration/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/moving-away-from-google-site-search-implementing-pagefind-for-static-sites-ij1">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>このブログのサイト内検索を、Google検索（&lt;code>site:&lt;/code>）から&lt;a href="https://pagefind.app/" target="_blank" rel="noopener noreferrer">Pagefind&lt;/a>
に移行しました。&lt;/p>
&lt;p>Hugoで生成した&lt;code>public/&lt;/code>をビルド後にPagefindでインデックス化し、静的サイト内で検索が完結する構成にします。&lt;/p></description></item><item><title>tmux-try: tryとtmuxを繋いで実験ディレクトリを即セッション化する</title><link>https://blog.tumf.dev/posts/diary/2026/2/1/tmux-try-session-manager/</link><pubDate>Sun, 01 Feb 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/2/1/tmux-try-session-manager/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/tmux-try-connecting-try-and-tmux-for-instant-session-creation-in-experiment-directories-46ej">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>「ちょっと試したいことがあるから、新しいディレクトリ作って、tmux起動して…」という作業を毎回やっていませんか？&lt;/p>
&lt;p>以前紹介した&lt;a href="https://github.com/tobi/try" target="_blank" rel="noopener noreferrer">try&lt;/a>
（詳細は「&lt;a href="https://blog.tumf.dev/posts/diary/2026/1/20/try-cli-experiment-directory-management/">try: 深夜2時のひらめきを翌朝見つけられるか？&lt;/a>
」参照）は実験用ディレクトリを日付プレフィックス付きで管理してくれる便利なツールですが、そこから&lt;a href="https://blog.tumf.dev/tags/tmux/">tmux&lt;/a>
セッションを起動するのは別作業でした。この2つを繋ぐために&lt;a href="https://github.com/tumf/tmux-try" target="_blank" rel="noopener noreferrer">tmux-try&lt;/a>
を作りました。&lt;/p></description></item><item><title>なんでも解説動画ジェネレーターを公開: URLを入れるだけでずんだもん達が解説</title><link>https://blog.tumf.dev/posts/diary/2026/1/31/nandemo-kaisetsu-movie-generator/</link><pubDate>Sat, 31 Jan 2026 12:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/31/nandemo-kaisetsu-movie-generator/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/announcing-the-universal-explanation-video-generator-just-enter-a-url-and-let-zundamon-and-friends-2070">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>技術ブログやドキュメントを読むのは好きだけど、動画で見たいときもある。そんなときに「URLを入れるだけで解説動画ができたらいいのに」と思って作りました。&lt;/p>
&lt;p>&lt;a href="https://github.com/tumf/movie-generator" target="_blank" rel="noopener noreferrer">なんでも解説動画ジェネレーター&lt;/a>
は、URLを入力するとずんだもんや四国めたんといったキャラクターが内容を解説する動画を自動生成するWebアプリです。&lt;/p>
&lt;p>この記事では、使い方と技術的な裏側を紹介します。&lt;/p></description></item><item><title>Compound Engineering: 技術的負債を「技術的資産」に変える80:20の法則</title><link>https://blog.tumf.dev/posts/diary/2026/1/31/compound-engineering-technical-debt-reversal/</link><pubDate>Sat, 31 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/31/compound-engineering-technical-debt-reversal/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/compound-engineering-transforming-technical-debt-into-technical-assets-with-the-8020-rule-4bdk">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>&lt;a href="https://every.to/" target="_blank" rel="noopener noreferrer">Every&lt;/a>
（テック/ビジネス系メディア「Every」を運営）が公開した&lt;a href="https://github.com/EveryInc/compound-engineering-plugin" target="_blank" rel="noopener noreferrer">Compound Engineering Plugin&lt;/a>
は、&lt;a href="https://www.anthropic.com/" target="_blank" rel="noopener noreferrer">Anthropic&lt;/a>
の&lt;a href="https://www.anthropic.com/claude-code" target="_blank" rel="noopener noreferrer">Claude Code&lt;/a>
（ターミナル向けAIコーディングアシスタント）用のプラグインです。&lt;/p>
&lt;p>「機能を追加するたびにコードベースが複雑になる」——これは従来のソフトウェア開発における常識でした。しかし、Compound Engineering Pluginはこの常識を逆転させます。「機能が増えるほど開発が楽になる」という、一見矛盾した状態を実現する開発手法です。&lt;/p>
&lt;p>本記事では、Compound Engineeringの核心である「Plan/Review 80%、実装 20%」という比率の意味と、技術的負債を資産に変える仕組みを解説します。&lt;/p></description></item><item><title>EIP-7702時代のAccount Abstraction: 4337が必要なケース</title><link>https://blog.tumf.dev/posts/diary/2026/1/30/eip-4337-7702-combined-strategy/</link><pubDate>Fri, 30 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/30/eip-4337-7702-combined-strategy/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/account-abstraction-in-the-era-of-eip-7702-cases-where-4337-is-necessary-12nd">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>&lt;a href="https://ethereum.org/" target="_blank" rel="noopener noreferrer">Ethereum&lt;/a>
でdApp（分散型アプリケーション）を作ると、ユーザーに「ウォレットを用意して」「ETHを買って」「ガス代を払って」とお願いすることになります。これが普及の壁です。&lt;/p>
&lt;p>Account Abstraction（アカウント抽象化）は、この壁を崩すための仕組みです。&lt;a href="https://eips.ethereum.org/EIPS/eip-4337" target="_blank" rel="noopener noreferrer">EIP-4337&lt;/a>
と&lt;a href="https://eips.ethereum.org/EIPS/eip-7702" target="_blank" rel="noopener noreferrer">EIP-7702&lt;/a>
という2つの仕様があります。&lt;/p>
&lt;p>ここで想定するのは、dApp側がガス代を肩代わりして、ユーザーがETHを持たずに操作できる「ガスレス」UXを提供したい文脈です（= 送信者としてのtx.originや、スポンサー/リレイヤー運用を含む）。&lt;/p>
&lt;p>結論から言うと、&lt;strong>EIP-7702の登場で、（ガスレス文脈でも）4337の出番は大幅に減りました&lt;/strong>。単一ユーザーのバッチ実行や権限管理は7702だけで実現できます。4337が必要なのは「パーミッションレスなガススポンサー」と「複数ユーザー集約」の2つのケースに限られます。&lt;/p>
&lt;p>本記事では、まず「なぜAccount Abstractionが必要か」を整理し、その上で7702と4337の使い分けを具体的に示します。&lt;/p></description></item><item><title>Browser Code: AIにuserscriptを育てさせる仕組み</title><link>https://blog.tumf.dev/posts/diary/2026/1/29/browser-code-userscript-ai-agent/</link><pubDate>Thu, 29 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/29/browser-code-userscript-ai-agent/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/browser-code-teaching-ai-to-grow-userscripts-3npj">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>既存のWebサイトに対して「ここだけもう少し使いやすくしたい」「自分のワークフローに合わせて表示や挙動を変えたい」と思うことはありませんか？&lt;/p>
&lt;p>「&lt;a href="https://blog.tumf.dev/tags/ai/">AI&lt;/a>
がブラウザを操作する」ツールは、&lt;a href="https://playwright.dev/" target="_blank" rel="noopener noreferrer">Playwright&lt;/a>
や &lt;a href="https://pptr.dev/" target="_blank" rel="noopener noreferrer">Puppeteer&lt;/a>
 で既に実現されています。でも&lt;a href="https://github.com/chebykinn/browser-code" target="_blank" rel="noopener noreferrer">Browser Code&lt;/a>
が狙っているのは、そこではありません。&lt;/p>
&lt;p>「AIが操作する」のではなく、「AIが常駐するuserscriptを育てて、サイトを自分仕様に作り替え続ける」。それがBrowser Codeの本質です。&lt;/p>
&lt;p>ブラウザ自動化（操作の再生）ではなく、userscriptの動的生成（改造の永続化）です。この違いを理解すると、どこで使えて、どこで使えないかが見えてきます。&lt;/p></description></item><item><title>並列でセッション管理: tmuxの代替を探したら結局tmuxが最強だった</title><link>https://blog.tumf.dev/posts/diary/2026/1/28/tmux-alternatives-comparison/</link><pubDate>Wed, 28 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/28/tmux-alternatives-comparison/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/session-management-in-parallel-in-search-of-a-tmux-alternative-only-to-find-tmux-is-the-best-2hfk">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>「&lt;a href="https://blog.tumf.dev/tags/tmux/">tmux&lt;/a>
重そう、もっと軽いのないかな？」&lt;/p>
&lt;p>100並列でAI開発環境のopencodeを動かすとき、ふとそう思いました。セッション管理ツールといえばtmuxですが、バイナリサイズも大きいし、もっとシンプルで軽量なツールがあるんじゃないか。そう考えて、tmuxの代替ツールを片っ端から試してみました。&lt;/p>
&lt;p>結論から言うと、&lt;strong>100並列ならtmuxが最軽量&lt;/strong>でした。&lt;/p></description></item><item><title>direnvとdotenvx-rsの組み合わせ: 自動ロードと暗号化を両立させる設定パターン</title><link>https://blog.tumf.dev/posts/diary/2026/1/27/direnv-dotenvx-rs-integration/</link><pubDate>Tue, 27 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/27/direnv-dotenvx-rs-integration/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/combining-direnv-and-dotenvx-rs-a-configuration-pattern-for-automatic-loading-and-encryption-3d1p">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>先日、プロジェクトの&lt;code>.env&lt;/code>ファイルをGitにコミットしたくて&lt;a href="https://github.com/linux-china/dotenvx-rs" target="_blank" rel="noopener noreferrer">dotenvx-rs&lt;/a>
で暗号化を試したんですが、毎回&lt;code>dotenvx run&lt;/code>を打つのが面倒で挫折しかけました。「&lt;a href="https://direnv.net/" target="_blank" rel="noopener noreferrer">direnv&lt;/a>
と組み合わせれば自動化できるのでは？」と思って試したところ、かなり快適な構成ができたので共有します。&lt;/p></description></item><item><title>SARA: Markdown要件を知識グラフで管理するCLI</title><link>https://blog.tumf.dev/posts/diary/2026/1/26/sara-markdown-requirements-knowledge-graph/</link><pubDate>Mon, 26 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/26/sara-markdown-requirements-knowledge-graph/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/sara-a-cli-tool-for-managing-markdown-requirements-with-knowledge-graphs-nco">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>「要件定義書はどこ？」「この設計、どの要件から来てるの？」「あれ、このリンク切れてる…」&lt;/p>
&lt;p>チームが大きくなると、要件や設計ドキュメントが散らばり始めます。&lt;a href="https://www.atlassian.com/software/confluence" target="_blank" rel="noopener noreferrer">Confluence&lt;/a>
、&lt;a href="https://www.notion.so/" target="_blank" rel="noopener noreferrer">Notion&lt;/a>
、Excel、Wiki、Markdown…ツールはバラバラ、リンクは切れ、誰も全体像を把握できません。&lt;/p>
&lt;p>&lt;a href="https://github.com/cledouarec/sara" target="_blank" rel="noopener noreferrer">SARA&lt;/a>
（Solution Architecture Requirement for Alignment）は、この問題を「Markdown + &lt;a href="https://git-scm.com/" target="_blank" rel="noopener noreferrer">Git&lt;/a>
 + 知識グラフ（ドキュメント同士の関係をグラフ構造で表したもの）」で解決するCLIツールです。要件をMarkdownで書き、YAMLフロントマター（Markdown先頭のメタ情報）で関係を定義するだけで、トレーサビリティ（要件から実装までを辿れる性質）を自動で検証できます。&lt;/p></description></item><item><title>MiroThinker: AIは「記憶」ではなく「調査」で賢くなる時代へ</title><link>https://blog.tumf.dev/posts/diary/2026/1/25/mirothinker-interactive-scaling/</link><pubDate>Sun, 25 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/25/mirothinker-interactive-scaling/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/mirothinker-a-new-era-where-ai-becomes-smarter-through-investigation-rather-than-memory-5an1">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>AIの性能を上げるには、モデルを大きくするしかない——そう信じられてきた常識が、いま覆されようとしています。&lt;/p>
&lt;p>&lt;a href="https://github.com/MiroMindAI/MiroThinker" target="_blank" rel="noopener noreferrer">MiroThinker&lt;/a>
は、&lt;a href="https://miromind.ai/" target="_blank" rel="noopener noreferrer">MiroMind&lt;/a>
社が開発したオープンソースの検索エージェントです。30Bパラメータという比較的小さなモデルでありながら、1兆パラメータ級のモデルを上回る性能を達成しています。その秘密は「Interactive Scaling」という新しいスケーリング手法にあります。&lt;/p></description></item><item><title>Qwen3-TTS: Apple Silicon M3で試したら日本語品質に驚いた——VoiceDesignで権利フリーの声を作る</title><link>https://blog.tumf.dev/posts/diary/2026/1/24/qwen3-tts-voice-design-clone-workflow/</link><pubDate>Sat, 24 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/24/qwen3-tts-voice-design-clone-workflow/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/qwen3-tts-surprised-by-the-quality-of-japanese-on-apple-silicon-m3-creating-rights-free-voices-k1d">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>「オープンソースのTTSで、ここまで自然な日本語が出るのか」——正直、驚きました。&lt;/p>
&lt;p>2026年1月22日に &lt;a href="https://www.alibabacloud.com/" target="_blank" rel="noopener noreferrer">Alibaba Cloud&lt;/a>
 のQwen Teamが公開した &lt;a href="https://github.com/QwenLM/Qwen3-TTS" target="_blank" rel="noopener noreferrer">Qwen3-TTS&lt;/a>
 を、手元のMacBook Air（Apple Silicon M3）で試してみました。結論から言うと、日本語の読み上げ品質がかなり良い。そして何より、&lt;strong>VoiceDesign機能で「自分だけの声」を作れる&lt;/strong>のが面白い。権利的にもクリーンな声を、自然言語の指示だけで生成できます。&lt;/p>
&lt;p>この記事では、Apple Silicon（MPS）での動作確認結果と、VoiceDesign→Cloneワークフローの実用性をまとめます。動作確認に使ったコードは &lt;a href="https://github.com/tumf/2026-01-23-Qwen3-TTS" target="_blank" rel="noopener noreferrer">GitHub&lt;/a>
 に置いてあります。&lt;/p></description></item><item><title>Open Paymaster: 誰も運営しないのに回るリバランス設計</title><link>https://blog.tumf.dev/posts/diary/2026/1/23/open-paymaster-sustainable-rebalance/</link><pubDate>Fri, 23 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/23/open-paymaster-sustainable-rebalance/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/open-paymaster-a-rebalancing-design-that-operates-without-management-40c3">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>&lt;a href="https://github.com/open-paymaster/open-paymaster-monorepo" target="_blank" rel="noopener noreferrer">Open Paymaster&lt;/a>
は、&lt;a href="https://eips.ethereum.org/EIPS/eip-4337" target="_blank" rel="noopener noreferrer">ERC-4337&lt;/a>
（Account Abstraction、アカウント抽象化）のPaymaster（ガス代を肩代わりするコントラクト）です。&lt;/p>
&lt;p>Paymasterの体験価値は、ユーザーがネイティブ通貨（ETH）を持っていなくても、ERC-20でガス代を払ってトランザクションを通せるところです。一方で、Paymaster自体は「誰かが面倒を見る」前提になりやすいのがしんどいポイントです。&lt;/p>
&lt;p>Open Paymasterは、ここを運営者の頑張りで解くのではなく、ユーザー/LP/リバランサーの3者インセンティブで自律的に回す方向に寄せています。この記事では、LP持分の実装（ERC-6909）ではなく、この「誰も運営しないのに回る」設計思想を中心に追います。&lt;/p></description></item><item><title>Zodで実装するNewtype Pattern: TypeScriptに欠けている型安全性を補う</title><link>https://blog.tumf.dev/posts/diary/2026/1/22/zod-branded-types-newtype-pattern/</link><pubDate>Thu, 22 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/22/zod-branded-types-newtype-pattern/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/implementing-the-newtype-pattern-with-zod-enhancing-type-safety-in-typescript-5c62">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>&lt;a href="https://www.typescriptlang.org/" target="_blank" rel="noopener noreferrer">TypeScript&lt;/a>
の型システムは構造的型付け（structural typing）です。つまり、構造が同じなら異なる型として扱われません。これが原因で、本来は区別すべき値を誤って混同してしまうバグが発生します。&lt;/p>
&lt;p>&lt;a href="https://zod.dev/" target="_blank" rel="noopener noreferrer">Zod&lt;/a>
のbranded types（ブランド型）を使えば、この問題を解決できます。これはNewtype Pattern（newtypeパターン、同じプリミティブ型に「意味の違う型」を与えて取り違えを防ぐ手法）をTypeScriptで実現する、かなり実用的なアプローチです。&lt;/p>
&lt;p>本記事では、branded typesの基本から実践的な使い方まで、実例とともに紹介します。&lt;/p></description></item><item><title>Robin: AIを武器にダークウェブを調査する - セキュリティ研究者の新しい相棒</title><link>https://blog.tumf.dev/posts/diary/2026/1/21/robin-ai-darkweb-osint-tool/</link><pubDate>Wed, 21 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/21/robin-ai-darkweb-osint-tool/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/robin-investigating-the-dark-web-with-ai-a-new-companion-for-security-researchers-53kj">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>ダークウェブでの情報収集は、セキュリティ研究者にとって不可欠な作業です。しかし、膨大なノイズの中から有用な情報を見つけ出すのは至難の業でした。&lt;a href="https://github.com/apurvsinghgautam/robin" target="_blank" rel="noopener noreferrer">Robin&lt;/a>
は、LLMの力を借りてこの問題を解決する新しいOSINTツールです。OSINT（Open Source Intelligence）は、公開情報をもとに目的に沿った情報を収集・整理する調査手法を指します。&lt;/p>
&lt;p>本記事では、Robinの概要、仕組み、そして公式README（2026-01-17時点のv2.0相当）に沿ったセットアップ方法を紹介します。CLIオプションやモデル名は更新されることがあるため、実行前に公式READMEも確認するのがおすすめです。&lt;/p></description></item><item><title>try: 深夜2時のひらめきを翌朝見つけられるか？ — ADHD開発者が作った実験ディレクトリ管理ツール</title><link>https://blog.tumf.dev/posts/diary/2026/1/20/try-cli-experiment-directory-management/</link><pubDate>Tue, 20 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/20/try-cli-experiment-directory-management/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/try-can-you-find-your-2-am-epiphany-the-next-morning-an-experimental-directory-management-tool-d83">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>深夜に思いついた小ネタを試して、雑にディレクトリを切って、雑にコードを書いて、雑に寝る。&lt;/p>
&lt;p>翌朝になって「昨日のあれ、どこに置いたっけ？」となるのがセットなんですが、これを何度もやると地味にストレスです。プロジェクトは増えるのに、手元のファイルシステムは一向に賢くならない。&lt;/p>
&lt;p>このブログのタイトルは&lt;code>Fragments of verbose memory&lt;/code>（冗長な記憶の断片）なんですが、試行錯誤の断片って、本当に放っておくと消えます。消えるというか、見つからなくなります。&lt;/p>
&lt;p>&lt;a href="https://github.com/tobi/try" target="_blank" rel="noopener noreferrer">try&lt;/a>
は、その「見つからなくなる」を減らしてくれるツールでした。実験用ディレクトリの作成・検索・移動がスッと繋がるので、散らかり始める手前で戻ってこれる。作者が&lt;a href="https://www.shopify.com/" target="_blank" rel="noopener noreferrer">Shopify&lt;/a>
のCEO &lt;a href="https://x.com/tobi" target="_blank" rel="noopener noreferrer">Tobi Lütke&lt;/a>
というのも面白いところです。&lt;/p></description></item><item><title>llm-tldr: 「認証はどこ？」に100msで答えるセマンティック検索の精度と限界</title><link>https://blog.tumf.dev/posts/diary/2026/1/19/llm-tldr-semantic-search/</link><pubDate>Mon, 19 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/19/llm-tldr-semantic-search/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/llm-tldr-answering-where-is-the-authentication-with-100ms-accuracy-and-limitations-of-3n9i">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>大規模なコードベースで「認証機能ってどこに実装されてるんだっけ？」と探したことはありませんか？&lt;code>grep&lt;/code>や&lt;code>find&lt;/code>では関数名がわからないと見つけられず、IDEのシンボル検索も完全一致が前提です。&lt;/p>
&lt;p>&lt;a href="https://github.com/parcadei/llm-tldr" target="_blank" rel="noopener noreferrer">llm-tldr&lt;/a>
は、自然言語クエリでコードを検索できるセマンティック検索機能を持つコード解析ツールです。「認証機能」「PDF生成」といった曖昧なキーワードでも、実際の振る舞いから関数を見つけ出します。本記事では、269ファイルのNext.jsプロジェクトで実際に試した結果から、その精度と限界を報告します。&lt;/p></description></item><item><title>LangExtract: 抽出結果に文字位置を付ける構造化データ抽出ライブラリ</title><link>https://blog.tumf.dev/posts/diary/2026/1/18/langextract-source-grounding/</link><pubDate>Sun, 18 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/18/langextract-source-grounding/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/langextract-a-structured-data-extraction-library-that-adds-character-positions-to-extraction-4ood">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>100社の有価証券報告書から「売上変動要因」を抽出したい。1000件の契約書から「解約条項」を探したい。こうした&lt;strong>大量文書からの情報抽出&lt;/strong>は、従来は人手で行うしかありませんでした。&lt;/p>
&lt;p>LLMの登場で「構造化データ抽出」が可能になりましたが、新たな問題が生まれました：&lt;strong>「この情報、本当にその文書に書いてあったのか？」&lt;/strong>&lt;/p>
&lt;p>&lt;a href="https://github.com/google/langextract" target="_blank" rel="noopener noreferrer">LangExtract&lt;/a>
は、この問題を解決するGoogleのオープンソース&lt;a href="https://blog.tumf.dev/tags/python/">Python&lt;/a>
ライブラリです。抽出結果に&lt;strong>文字位置&lt;/strong>（CharInterval）を付けることで、「どこから抽出したか」を明示できます。&lt;/p></description></item><item><title>superpowers: AIエージェントを「説得」する技術──心理学の原理がコード品質を変える理由</title><link>https://blog.tumf.dev/posts/diary/2026/1/17/superpowers-persuasion-psychology/</link><pubDate>Sat, 17 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/17/superpowers-persuasion-psychology/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/superpowers-the-technology-to-persuade-ai-agents-why-psychological-principles-change-code-quality-2d2f">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>「&lt;a href="https://blog.tumf.dev/tags/ai/">AI&lt;/a>
エージェントにTDDを徹底させたい」──そう思ったことはありませんか？&lt;/p>
&lt;p>&lt;a href="https://docs.claude.com/en/docs/claude-code" target="_blank" rel="noopener noreferrer">Claude Code&lt;/a>
や&lt;a href="https://www.cursor.com/" target="_blank" rel="noopener noreferrer">Cursor&lt;/a>
のようなAIコーディングエージェントは便利ですが、&lt;strong>急いでいるとスキルやベストプラクティスをスキップしてしまう&lt;/strong>問題があります。時間がないからテストを書かない、デバッグ手順を省略する、といった「人間らしい」判断をAIもしてしまうのです。&lt;/p>
&lt;p>&lt;a href="https://github.com/obra/superpowers" target="_blank" rel="noopener noreferrer">superpowers&lt;/a>
は、この問題に心理学の原理で挑むスキルフレームワークです。Robert Cialdiniの「影響力の武器」で知られる説得原理が&lt;a href="https://blog.tumf.dev/tags/llm/">LLM&lt;/a>
にも有効であることを学術的に検証し、AIエージェントに「スキルを守らせる」仕組みを実装しています。&lt;/p></description></item><item><title>claude-switcher: プロンプトをUnixパイプに流し込む発想</title><link>https://blog.tumf.dev/posts/diary/2026/1/16/claude-switcher-executable-markdown/</link><pubDate>Fri, 16 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/16/claude-switcher-executable-markdown/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/claude-switcher-the-concept-of-piping-prompts-into-unix-2o2h">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>先日、Hacker Newsで「&lt;a href="https://news.ycombinator.com/item?id=46549444" target="_blank" rel="noopener noreferrer">Executable Markdown files with Unix pipes&lt;/a>
」という投稿を見かけました。思わず「これは面白い」と唸りました。&lt;/p>
&lt;p>&lt;a href="https://github.com/andisearch/claude-switcher" target="_blank" rel="noopener noreferrer">claude-switcher&lt;/a>
を使うと、Markdownファイルの先頭に &lt;code>#!/usr/bin/env claude-run&lt;/code> というshebang（先頭行で実行コマンドを指定する仕組み）を書くだけで、そのファイルが実行可能になります。さらに、普通のUnixコマンドと同じようにパイプでつなげられる。&lt;/p>
&lt;div class="highlight">&lt;div class="chroma">
&lt;table class="lntable">&lt;tr>&lt;td class="lntd">
&lt;pre tabindex="0" class="chroma">&lt;code>&lt;span class="lnt">1
&lt;/span>&lt;span class="lnt">2
&lt;/span>&lt;/code>&lt;/pre>&lt;/td>
&lt;td class="lntd">
&lt;pre tabindex="0" class="chroma">&lt;code class="language-bash" data-lang="bash">&lt;span class="line">&lt;span class="cl">cat data.json &lt;span class="p">|&lt;/span> ./analyze.md &amp;gt; results.txt
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">git log -10 &lt;span class="p">|&lt;/span> ./summarize.md
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/td>&lt;/tr>&lt;/table>
&lt;/div>
&lt;/div>&lt;p>「LLMをパイプラインに組み込む」という発想が新鮮で、実際に動かしてみたくなりました。&lt;/p></description></item><item><title>Bunは速い、pnpmは正しい：2つのパッケージマネージャが示すJSエコシステムの未来</title><link>https://blog.tumf.dev/posts/diary/2026/1/15/bun-vs-pnpm-comparison/</link><pubDate>Thu, 15 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/15/bun-vs-pnpm-comparison/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/bun-is-fast-pnpm-is-correct-the-future-of-the-js-ecosystem-as-shown-by-two-package-managers-2l06">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>npmやYarnからの移行を検討していると、必ず選択肢に上がる&lt;a href="https://pnpm.io/" target="_blank" rel="noopener noreferrer">pnpm&lt;/a>
と&lt;a href="https://bun.sh/" target="_blank" rel="noopener noreferrer">Bun&lt;/a>
。どちらも「npmより速い」とアピールしていますが、実際のところ何が違うのでしょうか。&lt;/p>
&lt;p>State of JS 2024では、pnpmは「継続利用意向（retention）」が高く、開発者からの評価が安定していることがわかります。一方で、Bunも新しい選択肢として存在感を増しています。しかし、両者の設計思想は対照的です。pnpmは「正しい依存関係管理」を、Bunは「速度とDX」を追求しています。本記事では、この2つのパッケージマネージャの違いを整理し、あなたのプロジェクトに合った選択肢を見つけるヒントを提供します。&lt;/p></description></item><item><title>resticprofile: 除外パターン・世代管理・スケジュールを1つのYAMLで完結させる</title><link>https://blog.tumf.dev/posts/diary/2026/1/14/resticprofile-yaml-config-automation/</link><pubDate>Wed, 14 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/14/resticprofile-yaml-config-automation/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/resticprofile-consolidating-exclusion-patterns-generation-management-and-scheduling-in-a-single-1d2k">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>前回の記事「&lt;a href="https://blog.tumf.dev/posts/diary/2026/1/9/restic-developer-backup-strategy/">restic: node_modules と .git を除外しつつ「復元可能な開発環境」を維持する設計&lt;/a>
」では、restic の基本的な使い方と launchd/systemd を使った自動化まで解説しました。&lt;/p>
&lt;p>しかし、設定ファイルを複数管理したり、plist や unit ファイルを手書きするのは正直面倒です。macOS と Linux で異なる設定を維持するのも煩雑になりがちです。&lt;/p>
&lt;p>そこで本記事では、&lt;a href="https://creativeprojects.github.io/resticprofile/" target="_blank" rel="noopener noreferrer">resticprofile&lt;/a>
 を使って、バックアップ設定を&lt;strong>1つの YAML ファイルに集約&lt;/strong>する実践的な方法を紹介します。パスワード管理、除外リスト、世代管理、スケジュール——これらすべてを宣言的に管理できる快適さを体験しましょう。&lt;/p></description></item><item><title>Mole: ターミナルから始めるMac最適化の基本</title><link>https://blog.tumf.dev/posts/diary/2026/1/13/mole-mac-terminal-maintenance/</link><pubDate>Tue, 13 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/13/mole-mac-terminal-maintenance/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/mole-the-basics-of-mac-optimization-from-the-terminal-3p36">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>&lt;a href="https://github.com/tw93/Mole" target="_blank" rel="noopener noreferrer">Mole&lt;/a>
は、&lt;a href="https://www.apple.com/macos/" target="_blank" rel="noopener noreferrer">macOS&lt;/a>
向けの無料オープンソースクリーナーです。ターミナルから実行するCLI（Command Line Interface、コマンドラインで操作するUI）ツールで、&lt;a href="https://macpaw.com/cleanmymac" target="_blank" rel="noopener noreferrer">CleanMyMac&lt;/a>
、&lt;a href="https://freemacsoft.net/appcleaner/" target="_blank" rel="noopener noreferrer">AppCleaner&lt;/a>
、&lt;a href="https://daisydiskapp.com/" target="_blank" rel="noopener noreferrer">DaisyDisk&lt;/a>
、&lt;a href="https://bjango.com/mac/istatmenus/" target="_blank" rel="noopener noreferrer">iStat Menus&lt;/a>
が担っている「よく使うユースケース」を、1つのコマンドに寄せてカバーするイメージです。&lt;/p>
&lt;p>自分がこういうツールに興味を持ったのは、並列開発が増えてきて、ディスク容量やメモリなどのリソース枯渇に悩むことが増えたからです。年末の大掃除みたいに一回きれいにして終わりではなく、普段のメンテとして回せる形がほしくなりました。&lt;/p>
&lt;p>本記事では、Moleの基本的な使い方と、Mac開発者が「継続できるメンテ」に落とし込むためのポイントをまとめます。&lt;/p></description></item><item><title>Twitch Plays PokemonからOpen Chaosへ：群衆開発10年史と次の10年</title><link>https://blog.tumf.dev/posts/diary/2026/1/12/open-chaos-crowd-development-history/</link><pubDate>Mon, 12 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/12/open-chaos-crowd-development-history/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/from-twitch-plays-pokemon-to-open-chaos-a-decade-of-crowd-development-and-the-next-ten-years-1nmh">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>先日、&lt;a href="https://news.ycombinator.com/" target="_blank" rel="noopener noreferrer">Hacker News&lt;/a>
で387ポイントを獲得した&lt;a href="https://openchaos.dev/" target="_blank" rel="noopener noreferrer">Open Chaos&lt;/a>
というプロジェクトを見つけて、正直ワクワクしました。&lt;/p>
&lt;p>「コミュニティ投票で進化するOSS」——このコンセプト、実は10年以上前から形を変えながら進化してきた「群衆開発」の最新形です。2014年の&lt;a href="https://en.wikipedia.org/wiki/Twitch_Plays_Pok%C3%A9mon" target="_blank" rel="noopener noreferrer">Twitch Plays Pokemon&lt;/a>
から始まった実験が、2026年にどう姿を変えたのか。そしてAI時代に何が起きるのか。まとめておきます。&lt;/p></description></item><item><title>ralph-claude-code: AIエージェントを"止める"技術——サーキットブレーカーパターンが暴走を防ぐ仕組み</title><link>https://blog.tumf.dev/posts/diary/2026/1/11/ralph-claude-code-circuit-breaker/</link><pubDate>Sun, 11 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/11/ralph-claude-code-circuit-breaker/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/ralph-claude-code-the-technology-to-stop-ai-agents-how-the-circuit-breaker-pattern-prevents-3di4">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>「&lt;a href="https://claude.ai/code" target="_blank" rel="noopener noreferrer">Claude Code&lt;/a>
を無限ループで回したら一晩で6つのリポジトリが完成した」——そんなYCombinatorハッカソンの実験が話題になりました。これを実現しているのが&lt;a href="https://github.com/frankbria/ralph-claude-code" target="_blank" rel="noopener noreferrer">ralph-claude-code&lt;/a>
です。&lt;/p>
&lt;p>&lt;a href="https://blog.tumf.dev/tags/ai/">AI&lt;/a>
エージェントの自律ループは強力ですが、「いつ止めるか」が最大の課題です。止めるタイミングを間違えると、APIコストが爆発するか、同じエラーで延々とループし続けます。ralph-claude-codeは、サーキットブレーカーパターンと終了検出アルゴリズムでこの問題を解決しています。&lt;/p>
&lt;p>本記事では、既存記事では触れられていない&lt;strong>実装の内部ロジック&lt;/strong>に焦点を当て、どうやって「止める技術」が実現されているかを解説します。&lt;/p></description></item><item><title>.gitignore だけじゃない: Git ファイル無視の4つの方法と使い分け</title><link>https://blog.tumf.dev/posts/diary/2026/1/10/git-ignore-methods-comparison/</link><pubDate>Sat, 10 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/10/git-ignore-methods-comparison/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/not-just-gitignore-four-methods-to-ignore-files-in-git-and-how-to-use-them-1ad5">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>&lt;a href="https://blog.tumf.dev/tags/git/">Git&lt;/a>
でファイルを無視する方法として &lt;code>.gitignore&lt;/code> は有名ですが、実は他にも3つの方法があります。環境依存の設定ファイルをローカルだけ変更したい、巨大なSDKの差分チェックを省きたい、といったケースでは &lt;code>.gitignore&lt;/code> だけでは解決できません。&lt;/p>
&lt;p>本記事では、Gitのファイル無視方法4つを比較し、状況ごとの使い分けを整理します。&lt;/p></description></item><item><title>restic: node_modules と .git を除外しつつ「復元可能な開発環境」を維持する設計</title><link>https://blog.tumf.dev/posts/diary/2026/1/9/restic-developer-backup-strategy/</link><pubDate>Fri, 09 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/9/restic-developer-backup-strategy/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/restic-designing-a-restorable-development-environment-while-excluding-nodemodules-and-git-4ig">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>開発マシンのバックアップ、ちゃんと取っていますか？&lt;/p>
&lt;p>「Time Machineがあるから大丈夫」「node_modules は git clone すれば復元できるし&amp;hellip;」そう思っていた時期が私にもありました。でも、本当に必要な時に復元できないバックアップには意味がありません。&lt;/p>
&lt;p>&lt;a href="https://blog.tumf.dev/posts/diary/2025/12/28/engineer-year-end-cleanup-part2/">年末の大掃除記事（後編）&lt;/a>
で restic + resticprofile を紹介しましたが、「具体的にどう設定すればいいの？」という声をいただきました。本記事では、その深掘りとして restic を使った開発環境バックアップの実践的な設計を基礎から解説します。容量を無駄にせず、でも必要なものは確実に復元できる——そんなバランスの取れたバックアップ戦略を構築しましょう。&lt;/p></description></item><item><title>jj-desc: Rust製のjjコミットメッセージ自動生成ツールをリリース</title><link>https://blog.tumf.dev/posts/diary/2026/1/8/jj-desc-release/</link><pubDate>Thu, 08 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/8/jj-desc-release/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/jj-desc-release-of-the-rust-based-jj-commit-message-generation-tool-3mpf">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>&lt;a href="https://github.com/martinvonz/jj" target="_blank" rel="noopener noreferrer">Jujutsu（jj）&lt;/a>
のコミットメッセージをLLMで自動生成するCLIツール「&lt;a href="https://github.com/tumf/jj-desc" target="_blank" rel="noopener noreferrer">jj-desc&lt;/a>
」をリリースしました。&lt;/p>
&lt;p>jjはGoogleが開発しているGit互換のバージョン管理ツールで、強力なundo機能とrevset（リビジョンセット）による柔軟なコミット操作が特徴です。生成されるコミットメッセージは&lt;a href="https://www.conventionalcommits.org/" target="_blank" rel="noopener noreferrer">Conventional Commits&lt;/a>
形式に従います。jj-descはこのjjの特性を活かし、複数のコミットメッセージを一括で生成できる点が大きな特徴となっています。&lt;/p></description></item><item><title>Tailscaleの『なんとなく不安』を数値化する：tailsnitchが暴く50の設定ミス</title><link>https://blog.tumf.dev/posts/diary/2026/1/7/tailsnitch-tailscale-security-audit/</link><pubDate>Wed, 07 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/7/tailsnitch-tailscale-security-audit/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/quantifying-the-vague-anxiety-of-tailscale-tailsnitch-exposes-50-configuration-mistakes-1cm9">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>2025年9月、アサヒグループホールディングスがランサムウェア攻撃を受けました。侵入経路はVPN装置の脆弱性。10月にはアスクルが業務委託先のVPNアカウント経由で侵入され、ECサイトが停止しました。&lt;/p>
&lt;p>どちらも「VPNさえあれば安全」という思い込みが招いた被害です。&lt;/p>
&lt;p>Tailscaleを導入したあなたは、こう思っているかもしれません。「従来のVPNより安全なはずだから大丈夫」と。&lt;/p>
&lt;p>確かにTailscaleには、従来のオンプレVPNゲートウェイと比べて優位性があります。WireGuardによる軽量で監査済みの暗号化、デバイス単位のゼロトラスト認証、VPN装置の脆弱性を突かれるリスクがないSaaS型アーキテクチャ——これらは従来VPNの弱点を解消する設計です。&lt;/p>
&lt;p>しかし、Tailscaleも設定を誤れば危険です。デフォルトACLを放置すれば全デバイスが無制限にアクセス可能になり、再利用可能な認証キーが漏洩すれば攻撃者が不正デバイスを追加できます。&lt;a href="https://github.com/Adversis/tailsnitch" target="_blank" rel="noopener noreferrer">tailsnitch&lt;/a>
は、そんな「なんとなく不安」を50以上のチェック項目で数値化し、Critical/High/Medium/Low/Infoの5段階で評価してくれるセキュリティ監査ツールです。&lt;/p>
&lt;p>本記事では、tailsnitchの使い方と、実際に検出される危険な設定ミスについて解説します。&lt;/p></description></item><item><title>jj workspace: コンフリクトで止まらないvibe coding並列開発</title><link>https://blog.tumf.dev/posts/diary/2026/1/6/jj-workspace-vibe-coding-parallel-development/</link><pubDate>Tue, 06 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/6/jj-workspace-vibe-coding-parallel-development/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/jj-workspace-parallel-development-with-vibe-coding-without-getting-stopped-by-conflicts-3m9k">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>最近、&lt;a href="https://www.anthropic.com/news/claude-code" target="_blank" rel="noopener noreferrer">Claude Code&lt;/a>
を4並列で動かしながら開発していて、ちょっと困ったことがありました。&lt;/p>
&lt;p>&lt;code>git worktree&lt;/code>で4つのディレクトリを作って、それぞれでAIに実装を任せる——ここまでは快適なんですが、いざマージしようとすると「CONFLICT」の嵐。1つのworktreeがコンフリクトで止まると、そこから派生させたい作業も全部ブロックされて、結局AIを遊ばせることになってしまう。&lt;/p>
&lt;p>「コンフリクトが起きても作業を止めたくないんだけど&amp;hellip;」と思って調べていたら、Googleのエンジニアが中心となって開発している&lt;a href="https://github.com/jj-vcs/jj" target="_blank" rel="noopener noreferrer">Jujutsu&lt;/a>
（jj）というVCSを見つけました。これがなかなか良くて、vibe codingスタイルにかなりハマったので共有します。&lt;/p></description></item><item><title>Vibium: PlaywrightよりAIエージェントに最適化されたブラウザ自動化ツール</title><link>https://blog.tumf.dev/posts/diary/2026/1/5/vibium-selenium-creator-browser-automation/</link><pubDate>Mon, 05 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/5/vibium-selenium-creator-browser-automation/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/vibium-a-browser-automation-tool-optimized-for-ai-agents-over-playwright-5hai">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>Seleniumの生みの親Jason Hugginsが、Selenium以来約20年ぶりとなる新しいブラウザ自動化ツール&lt;a href="https://github.com/VibiumDev/vibium" target="_blank" rel="noopener noreferrer">Vibium&lt;/a>
を発表しました。本記事では、Vibiumの設計思想、PlaywrightやPuppeteerとの違い、そしてなぜAIエージェント時代に新たなツールが必要だったのかを解説します。&lt;/p></description></item><item><title>docker-android: WebブラウザからAndroidエミュレータを操作するDocker環境</title><link>https://blog.tumf.dev/posts/diary/2026/1/4/docker-android-web-browser-remote-control/</link><pubDate>Sun, 04 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/4/docker-android-web-browser-remote-control/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/docker-android-a-docker-environment-for-controlling-android-emulators-from-a-web-browser-9lg">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>&lt;a href="https://github.com/budtmo/docker-android" target="_blank" rel="noopener noreferrer">docker-android&lt;/a>
は、Android エミュレータを&lt;a href="https://blog.tumf.dev/tags/docker/">Docker&lt;/a>
コンテナ内で動作させ、Web ブラウザから遠隔操作できるようにするオープンソースプロジェクトです。Android Studioをインストールすることなく、CI/CD パイプラインでの&lt;a href="https://blog.tumf.dev/tags/test/">テスト&lt;/a>
自動化やクラウド環境でのスケーラブルな Android テスト基盤を構築できます。&lt;/p>
&lt;p>本記事では、docker-android の概要、セットアップ方法、基本的な使い方、そして実践的な活用例を紹介します。&lt;/p></description></item><item><title>AI×Web3から見える2026年の大胆予測: エージェントがウォレットを持つ時代</title><link>https://blog.tumf.dev/posts/diary/2026/1/3/ai-web3-2026-bold-predictions/</link><pubDate>Sat, 03 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/3/ai-web3-2026-bold-predictions/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/bold-predictions-for-2026-from-the-intersection-of-ai-and-web3-the-era-of-agents-with-wallets-5ac7">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>2025年の&lt;a href="https://blog.tumf.dev/tags/ai/">AI&lt;/a>
業界と&lt;a href="https://blog.tumf.dev/tags/web3/">Web3&lt;/a>
業界を振り返ると、それぞれが独自の進化を遂げた1年でした。しかし、2026年に向けて本当に面白くなるのは、この2つの領域が&lt;strong>相互作用を起こし始める&lt;/strong>ところです。&lt;/p>
&lt;p>AIエージェントがスマートコントラクトを操作し、オンチェーンAIが分散型インフラ上で動き、トークンエコノミーがAI開発を加速する。2025年までに揃った技術的な土台の上で、2026年はこうした融合が「実験」から「実用」へ移行する年になるでしょう。&lt;/p>
&lt;p>本記事では、2025年のAI業界総括（&lt;a href="https://blog.tumf.dev/posts/diary/2026/1/1/ai-industry-2025-recap/">DeepSeekショックから始まった激動の1年&lt;/a>
）とWeb3業界総括（&lt;a href="https://blog.tumf.dev/posts/diary/2026/1/2/web3-industry-2025-recap/">プロダクトとして実装された技術たち&lt;/a>
）を踏まえつつ、「AIとWeb3が交わる未来」を大胆に予測します。&lt;/p></description></item><item><title>Web3業界2025年総括: プロダクトとして実装された技術たち</title><link>https://blog.tumf.dev/posts/diary/2026/1/2/web3-industry-2025-recap/</link><pubDate>Fri, 02 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/2/web3-industry-2025-recap/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/summary-of-the-web3-industry-in-2025-technologies-implemented-as-products-242j">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>2025年の&lt;a href="https://blog.tumf.dev/tags/blockchain/">Blockchain&lt;/a>
業界を振り返ると、象徴的だったのは「&lt;strong>技術がプロダクトとして触れる形になった&lt;/strong>」ことでした。&lt;/p>
&lt;p>長らく議論されていたAccount Abstraction（アカウント抽象化）は&lt;strong>EIP-7702&lt;/strong>としてメインネットに載り、断片化していたLayer 2は&lt;strong>Superchain&lt;/strong>としてつながり、DeFiは&lt;strong>Hooks&lt;/strong>によってアプリケーション層を取り込みました。&lt;/p>
&lt;p>本記事では、「仕様策定」や「テストネット」ではなく、実際に&lt;strong>メインネットで稼働し、ユーザー体験を変えた技術実装&lt;/strong>にフォーカスして2025年を振り返ります。&lt;/p></description></item><item><title>AI業界2025年総括: DeepSeekショックから始まった激動の1年</title><link>https://blog.tumf.dev/posts/diary/2026/1/1/ai-industry-2025-recap/</link><pubDate>Thu, 01 Jan 2026 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2026/1/1/ai-industry-2025-recap/</guid><description>&lt;p>2025年の&lt;a href="https://blog.tumf.dev/tags/ai/">AI&lt;/a>
業界を振り返ると、1月のDeepSeekショックに始まり、推論モデル競争の激化、そして「Vibe Coding」に象徴される開発体験の変化がとても印象的でした。&lt;/p>
&lt;p>ただ、いま（数カ月たった目線）で振り返ると、重要だったのは「新モデルが出た」事実そのものよりも、&lt;/p>
&lt;ul>
&lt;li>それが&lt;strong>何を当たり前に変えたのか&lt;/strong>&lt;/li>
&lt;li>それが&lt;strong>どんな実装・運用の形を定着させたのか&lt;/strong>&lt;/li>
&lt;/ul>
&lt;p>という“後から効いてくる変化”だった気がします。&lt;/p>
&lt;p>本記事では、年表として便利なWikipedia（&lt;a href="https://en.wikipedia.org/wiki/2025_in_artificial_intelligence" target="_blank" rel="noopener noreferrer">2025 in artificial intelligence&lt;/a>
）を軸にしつつ、OpenAI / Google DeepMind / Hugging Face / LangChain などの一次情報へのリンクを差し込みながら、月別に「結局どんな意味があったのか」まで含めて振り返ります。&lt;/p></description></item><item><title>fastmcp-gsuite: 決算作業で活躍したMCPサーバとこの2週間のアップデート</title><link>https://blog.tumf.dev/posts/diary/2025/12/31/fastmcp-gsuite-2-weeks-update/</link><pubDate>Wed, 31 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/31/fastmcp-gsuite-2-weeks-update/</guid><description>&lt;p>年末の決算作業、正直しんどいですよね。「あの領収書、メールで来てたはずだけどどこ行った&amp;hellip;」「カレンダーから出張日程を洗い出さないと&amp;hellip;」みたいな作業が延々と続くわけです。&lt;/p>
&lt;p>今回、そんな地獄の作業を救ってくれたのが、自分で作った&lt;a href="https://modelcontextprotocol.io/" target="_blank" rel="noopener noreferrer">MCPサーバ&lt;/a>
（Model Context Protocol）の&lt;a href="https://github.com/tumf/fastmcp-gsuite" target="_blank" rel="noopener noreferrer">fastmcp-gsuite&lt;/a>
でした。&lt;a href="https://claude.ai/download" target="_blank" rel="noopener noreferrer">Claude Desktop&lt;/a>
から「12月の経費メール探して」って言うだけで、&lt;a href="https://workspace.google.com/" target="_blank" rel="noopener noreferrer">Google Workspace&lt;/a>
のGmail、Calendar、Driveを横断検索してくれる。これがなかったら年越しできなかったかもしれません。&lt;/p></description></item><item><title>Turso Database: MCPサーバー搭載SQLiteがAIエージェント時代のDB設計を変える</title><link>https://blog.tumf.dev/posts/diary/2025/12/30/turso-mcp-server-ai-agent-database/</link><pubDate>Tue, 30 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/30/turso-mcp-server-ai-agent-database/</guid><description>&lt;p>&lt;a href="https://github.com/tursodatabase/turso" target="_blank" rel="noopener noreferrer">Turso Database&lt;/a>
は、SQLiteをRustで完全に書き直したインプロセスSQLデータベースです。特筆すべきは、&lt;strong>MCPサーバーモードを搭載&lt;/strong>している点で、AIエージェントが自然言語でデータベースを操作できるようになります。&lt;/p>
&lt;p>本記事では、Turso DatabaseのMCP機能の仕組みと、なぜAIエージェント時代にこのような設計が重要なのかを解説します。&lt;/p>
&lt;p>MCP Server の接続パターン自体を先に見たい場合は、&lt;a href="https://blog.tumf.dev/posts/diary/2026/2/10/qmd-obsidian-claude-code-mcp/">Claude CodeでObsidianを高速検索: qmd MCPサーバーの設定と活用&lt;/a>
 や &lt;a href="https://blog.tumf.dev/posts/diary/2025/12/9/claude-code-google-analytics-mcp/">Claude Code で GA4 にアクセスする - Google Analytics MCP Server の活用&lt;/a>
 を先に読むと理解しやすいです。&lt;/p></description></item><item><title>A2UI: AIエージェントが安全にUIを生成するGoogleの新プロトコル</title><link>https://blog.tumf.dev/posts/diary/2025/12/29/a2ui-agent-ui-protocol/</link><pubDate>Mon, 29 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/29/a2ui-agent-ui-protocol/</guid><description>&lt;p>AIエージェントがリッチなユーザーインターフェースを生成する際、セキュリティと表現力のトレードオフに直面します。テキストのみの応答では物足りず、かといって任意のコードを実行させるのは危険です。&lt;a href="https://www.google.com/" target="_blank" rel="noopener noreferrer">Google&lt;/a>
が主導する&lt;a href="https://a2ui.org/" target="_blank" rel="noopener noreferrer">A2UI&lt;/a>
（Agent-to-User Interface）は、この問題を「データのように安全、コードのように表現力豊か」なアプローチで解決する新しいオープンソースプロトコルです。&lt;/p>
&lt;p>本記事では、v0.8 Public Previewとして公開されたばかりのA2UIの概要、技術的特徴、そして実装例について紹介します。&lt;/p></description></item><item><title>エンジニアの年末大掃除 2025（後編）：ディスク容量の奪還とバックアップ体制の見直し</title><link>https://blog.tumf.dev/posts/diary/2025/12/28/engineer-year-end-cleanup-part2/</link><pubDate>Sun, 28 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/28/engineer-year-end-cleanup-part2/</guid><description>&lt;p>&lt;a href="https://blog.tumf.dev/posts/diary/2025/12/27/engineer-year-end-cleanup-part1/">前編&lt;/a>
では、1年間の統計振り返りとGitリポジトリの大掃除を行いました。後編では、ディスク容量の奪還とシステム環境の最適化に取り組みます。&lt;/p>
&lt;p>node_modules、Dockerイメージ、Homebrewの古いパッケージ&amp;hellip;。これらを一掃して、新年を軽快なマシンで迎えましょう。&lt;/p></description></item><item><title>エンジニアの年末大掃除 2025（前編）：統計で振り返る1年とGitリポジトリの棚卸し</title><link>https://blog.tumf.dev/posts/diary/2025/12/27/engineer-year-end-cleanup-part1/</link><pubDate>Sat, 27 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/27/engineer-year-end-cleanup-part1/</guid><description>&lt;p>年末年始、あなたのホームディレクトリは大丈夫ですか？未コミットのコード、マージ済みなのに残っている放置ブランチ、1年以上触っていないプロジェクト&amp;hellip;。新年を迎える前に、開発環境をクリーンな状態にリセットしましょう。&lt;/p>
&lt;p>前編では、1年間の開発活動を統計で振り返り、Gitリポジトリの大掃除を行います。新しいRust製OSSツールと実用的なスクリプトで、効率的に整理していきましょう。&lt;/p></description></item><item><title>Kaiju Engine: Unity比3倍高速の秘密とGoでゲームエンジンを書く理由</title><link>https://blog.tumf.dev/posts/diary/2025/12/26/kaiju-go-vulkan-game-engine/</link><pubDate>Fri, 26 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/26/kaiju-go-vulkan-game-engine/</guid><description>&lt;p>「ゲームエンジンを&lt;a href="https://blog.tumf.dev/tags/golang/">Go&lt;/a>
で書く」と聞いて、あなたはどう思いますか？C++が当たり前のゲーム開発業界で、ガベージコレクション（GC）を持つGo言語を選ぶのは、一見すると狂気の沙汰に見えるかもしれません。&lt;/p>
&lt;p>しかし、&lt;a href="https://github.com/KaijuEngine/kaiju" target="_blank" rel="noopener noreferrer">Kaiju Engine&lt;/a>
は、その常識に真っ向から挑戦しています。Goと&lt;a href="https://www.vulkan.org/" target="_blank" rel="noopener noreferrer">Vulkan&lt;/a>
で構築された2D/3Dゲームエンジンで、開発者によれば「同条件でUnityの3倍以上高速」という計測結果を公開しています。本記事では、なぜGoでゲームエンジンを書くのか、そしてなぜ高速なのかを技術的に解説します。&lt;/p></description></item><item><title>LEANN: 97%ストレージ削減のプライベートRAGシステム徹底解説</title><link>https://blog.tumf.dev/posts/diary/2025/12/25/leann-private-rag-system/</link><pubDate>Thu, 25 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/25/leann-private-rag-system/</guid><description>&lt;p>&lt;img 
 src="https://blog.tumf.dev/images/leann-private-rag-system/cover.png" 
 alt="LEANN: 97%ストレージ削減のプライベートRAGシステム徹底解説"
 loading="lazy"
 decoding="async"
/>
&lt;/p>
&lt;p>オープンソースのプライベート&lt;a href="https://blog.tumf.dev/tags/rag/">RAG&lt;/a>
システム &lt;a href="https://github.com/yichuan-w/LEANN" target="_blank" rel="noopener noreferrer">LEANN&lt;/a>
 が注目を集めています。本記事では、驚異的な97%のストレージ削減を実現しながら高速・高精度を両立するこのシステムについて、その革新的な仕組みと実装方法を詳しく解説します。&lt;/p></description></item><item><title>supabase db push はなぜ失敗するのか: マイグレーションの本質を理解する</title><link>https://blog.tumf.dev/posts/diary/2025/12/24/supabase-migration-complete-guide/</link><pubDate>Wed, 24 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/24/supabase-migration-complete-guide/</guid><description>&lt;p>先日、&lt;a href="https://supabase.com/" target="_blank" rel="noopener noreferrer">Supabase&lt;/a>
で開発中のプロジェクトで &lt;code>supabase db push&lt;/code> したら、いきなりエラーで止まって焦りました。&lt;/p>
&lt;p>「え、昨日まで動いてたのに&amp;hellip;」と思いながらエラーメッセージを読むと &lt;code>relation &amp;quot;users&amp;quot; already exists&lt;/code> とか &lt;code>migration history is not in sync&lt;/code> とか、なんだか不穏な文言が並んでいる。&lt;/p>
&lt;p>結局2時間くらい溶かして原因を突き止めたんですが、振り返ると&lt;strong>マイグレーションの仕組みをちゃんと理解してなかった&lt;/strong>のが問題でした。同じ轍を踏む人が減るよう、ハマりポイントと対処法をまとめておきます。&lt;/p>
&lt;p>特に&lt;a href="https://cursor.sh/" target="_blank" rel="noopener noreferrer">Cursor&lt;/a>
や&lt;a href="https://github.com/supabase-community/supabase-mcp" target="_blank" rel="noopener noreferrer">Supabase MCP&lt;/a>
でAIにスキーマ変更させてる人は要注意です。自分もこれでやらかしました。&lt;/p></description></item><item><title>exo 1.0: RDMA over Thunderbolt 5で分散AI推論が最大3.2倍高速化</title><link>https://blog.tumf.dev/posts/diary/2025/12/23/exo-1.0-rdma-thunderbolt5-performance/</link><pubDate>Tue, 23 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/23/exo-1.0-rdma-thunderbolt5-performance/</guid><description>&lt;p>2025年12月18日、&lt;a href="https://github.com/exo-explore/exo" target="_blank" rel="noopener noreferrer">exo&lt;/a>
のバージョン1.0が正式リリースされました。最大の目玉機能は&lt;strong>RDMA over Thunderbolt 5対応&lt;/strong>です。これにより、複数台のMac Studioを接続した際の分散AI推論が劇的に高速化されました。以前&lt;a href="https://blog.tumf.dev/posts/diary/2025/1/4/exo-first-impression/">当ブログで紹介したexo&lt;/a>
や&lt;a href="https://blog.tumf.dev/posts/diary/2025/12/15/macos-rdma-thunderbolt-exo-ai-cluster/">macOS 26.2のRDMA機能&lt;/a>
の続報となります。&lt;/p></description></item><item><title>DeepAudit vs PentestGPT: マルチエージェント監査はペンテストツールを超えるか</title><link>https://blog.tumf.dev/posts/diary/2025/12/22/deepaudit-vs-pentestgpt-ai-security-audit/</link><pubDate>Mon, 22 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/22/deepaudit-vs-pentestgpt-ai-security-audit/</guid><description>&lt;p>セキュリティ監査にAIを活用する流れが本格化しています。中国発のオープンソース脆弱性ハンティングツール&lt;a href="https://github.com/lintsinghua/DeepAudit" target="_blank" rel="noopener noreferrer">DeepAudit&lt;/a>
が注目を集める一方、既存の&lt;a href="https://github.com/GreyDGL/PentestGPT" target="_blank" rel="noopener noreferrer">PentestGPT&lt;/a>
も進化を続けています。本記事では、マルチエージェント協調型とペネトレーションテスト型という2つのアプローチを比較し、それぞれの実力と使い分けを整理します。&lt;/p></description></item><item><title>AI時代に「人月」はもう限界かもしれない</title><link>https://blog.tumf.dev/posts/diary/2025/12/21/spectalk-ai-estimation-mannmonth-myth/</link><pubDate>Sun, 21 Dec 2025 16:08:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/21/spectalk-ai-estimation-mannmonth-myth/</guid><description>&lt;p>&lt;img 
 src="https://blog.tumf.dev/images/spectalk-ai-estimation-mannmonth-myth/cover.png" 
 alt="SpecTalk cover image"
 loading="lazy"
 decoding="async"
/>
&lt;/p>
&lt;p>&lt;a href="https://opencode.ai/" target="_blank" rel="noopener noreferrer">OpenCode&lt;/a>
、&lt;a href="https://cursor.sh/" target="_blank" rel="noopener noreferrer">Cursor&lt;/a>
、&lt;a href="https://docs.anthropic.com/en/docs/claude-code" target="_blank" rel="noopener noreferrer">Claude Code&lt;/a>
——AIコーディング支援ツールを使っていると、ふと気づくことがあります。「この作業、昔なら2日かかってたな」と。&lt;/p>
&lt;p>生産性が上がるのは良いことです。しかし、見積もりの現場では厄介な問題が起きています。&lt;strong>「人月」という単位が、いよいよ機能しなくなってきた&lt;/strong>のです。&lt;/p></description></item><item><title>この数年のTUIアプリの進化 - Bubble TeaとRatatuiが牽引する黄金時代</title><link>https://blog.tumf.dev/posts/diary/2025/12/21/tui-evolution-2023-2024/</link><pubDate>Sun, 21 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/21/tui-evolution-2023-2024/</guid><description>&lt;p>ここ数年、ターミナル上で動作するTUI（Terminal User Interface）アプリが目覚ましい進化を遂げています。&lt;code>lazydocker&lt;/code>、&lt;code>yazi&lt;/code>、&lt;code>lazygit&lt;/code>など、洗練されたインターフェースを持つツールが次々と登場しています。&lt;/p>
&lt;p>特に&lt;strong>2023年は「TUIのカンブリア紀&lt;/strong>」とも呼べる爆発的な進化の年でした。Ratatuiの正式化を契機に、多様なTUIアプリケーションが一気に開花したのです。&lt;/p>
&lt;p>本記事では、この背景にあるTUIライブラリの進化と、2023-2024年に起きた重要な転換点について解説します。&lt;/p></description></item><item><title>Chatterboxの透かし技術Perth Watermarker：AI生成音声の出所証明の仕組み</title><link>https://blog.tumf.dev/posts/diary/2025/12/20/chatterbox-perth-watermarker-audio-proof/</link><pubDate>Sat, 20 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/20/chatterbox-perth-watermarker-audio-proof/</guid><description>&lt;p>AI音声合成技術の進化により、誰でも簡単に自然な音声を生成できる時代になりました。しかし、その一方で「この音声は本当に本人が話したものなのか？」「AIが生成した音声ではないのか？」という疑問が常につきまといます。&lt;/p>
&lt;p>この問題に対して、&lt;a href="https://www.resemble.ai/" target="_blank" rel="noopener noreferrer">Resemble AI&lt;/a>
が開発したオープンソースTTS（Text-to-Speech）エンジン「&lt;a href="https://github.com/resemble-ai/chatterbox" target="_blank" rel="noopener noreferrer">Chatterbox&lt;/a>
」は、ユニークな解決策を提示しています。それが&lt;strong>Perth Watermarker&lt;/strong>という、人間には知覚できないニューラルウォーターマーク技術です。&lt;/p>
&lt;p>本記事では、まだ日本ではほとんど知られていないChatterboxの全貌と、その核心技術であるPerth Watermarkerの仕組みを深掘りしていきます。&lt;/p></description></item><item><title>Auth0の代替に！オープンソース認証基盤Authgear Serverのセルフホスト入門</title><link>https://blog.tumf.dev/posts/diary/2025/12/19/authgear-passwordless-passkey-introduction/</link><pubDate>Fri, 19 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/19/authgear-passwordless-passkey-introduction/</guid><description>&lt;p>認証サービスをクラウドに依存せず、自社インフラで完全にコントロールしたいというニーズが高まっています。&lt;a href="https://github.com/authgear/authgear-server" target="_blank" rel="noopener noreferrer">Authgear Server&lt;/a>
は、&lt;a href="https://auth0.com/" target="_blank" rel="noopener noreferrer">Auth0&lt;/a>
や&lt;a href="https://firebase.google.com/products/auth" target="_blank" rel="noopener noreferrer">Firebase Auth&lt;/a>
の代替として使えるオープンソースの認証基盤です。本記事では、Docker Composeを使ったローカル環境でのセットアップから、Kubernetes上での本番デプロイまで、実践的に解説します。&lt;/p></description></item><item><title>next-ai-draw-io: 『アーキテクチャ図を言葉で描く』時代が来た</title><link>https://blog.tumf.dev/posts/diary/2025/12/18/next-ai-draw-io-architecture-diagram-with-ai/</link><pubDate>Thu, 18 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/18/next-ai-draw-io-architecture-diagram-with-ai/</guid><description>&lt;p>「Kubernetesクラスタの構成図を作って」と言うだけでdraw.ioの図が自動生成される。そんな時代が現実になりつつあります。&lt;/p>
&lt;p>GitHub Trendingで1週間に4,500以上のスターを集めた&lt;a href="https://github.com/DayuanJiang/next-ai-draw-io" target="_blank" rel="noopener noreferrer">next-ai-draw-io&lt;/a>
は、自然言語からdraw.io形式のアーキテクチャ図を生成するオープンソースツールです。本記事では、その仕組みと使い方、そしてMermaidとの使い分けについて解説します。&lt;/p></description></item><item><title>TOON - LLMプロンプトのトークン数を削減する新しいデータフォーマット</title><link>https://blog.tumf.dev/posts/diary/2025/12/17/toon-format-introduction/</link><pubDate>Wed, 17 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/17/toon-format-introduction/</guid><description>&lt;p>LLM（大規模言語モデル）を使った開発で、プロンプトのトークン数が気になったことはありませんか？JSONでデータを渡すと、どうしても冗長になりがちです。そんな課題を解決するために登場したのが「&lt;a href="https://toonformat.dev" target="_blank" rel="noopener noreferrer">TOON（Token-Oriented Object Notation）&lt;/a>
」という新しいデータフォーマットです。&lt;/p>
&lt;p>TOONは、LLM入力用に最適化されたコンパクトで人間が読みやすいJSONの代替フォーマットで、同じデータをJSONより約40%少ないトークン数で表現できます。この記事では、TOONの基本的な概要と、なぜLLM開発者にとって有用なのかを解説します。&lt;/p></description></item><item><title>uncloud: Swarm 難民のためDocker軽量マルチホストデプロイ</title><link>https://blog.tumf.dev/posts/diary/2025/12/16/uncloud-docker-kubernetes-gap/</link><pubDate>Tue, 16 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/16/uncloud-docker-kubernetes-gap/</guid><description>&lt;p>&lt;a href="https://docs.docker.com/engine/swarm/" target="_blank" rel="noopener noreferrer">Docker Swarm&lt;/a>
の開発停滞により、シンプルなマルチホストオーケストレーションを求める開発者たちは新たな選択肢を探しています。「Kubernetesは大げさすぎるけど、Docker Composeだけでは物足りない」――そんなSwarm難民の声に応えるツールが登場しました。&lt;/p>
&lt;p>&lt;a href="https://github.com/psviderski/uncloud" target="_blank" rel="noopener noreferrer">uncloud&lt;/a>
は、複数のDockerホスト間でコンテナ化アプリケーションをデプロイ・管理する軽量ツールです。Kubernetesのような中央制御プレーン（control plane）を持たず、各マシンがピアツーピア（P2P）でクラスター状態を同期する分散型アーキテクチャを採用しています。&lt;/p>
&lt;p>この記事では、uncloudのアーキテクチャの特徴、実際の使用方法、そしてSwarmやKubernetesなど他のツールとの違いについて解説します。&lt;/p></description></item><item><title>macOS 26.2のRDMA over Thunderbolt: exoと組み合わせて自宅AIクラスタを構築する</title><link>https://blog.tumf.dev/posts/diary/2025/12/15/macos-rdma-thunderbolt-exo-ai-cluster/</link><pubDate>Mon, 15 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/15/macos-rdma-thunderbolt-exo-ai-cluster/</guid><description>&lt;p>&lt;a href="https://www.apple.com/" target="_blank" rel="noopener noreferrer">Apple&lt;/a>
がmacOS Tahoe 26.2で&lt;strong>RDMA over Thunderbolt&lt;/strong>を有効化しました。これにより、複数のMacをThunderboltケーブルで接続し、高速なAIクラスタを構築できるようになります。以前当ブログで紹介した&lt;a href="https://blog.tumf.dev/posts/diary/2025/1/4/exo-first-impression/">exo&lt;/a>
や&lt;a href="https://blog.tumf.dev/posts/diary/2025/12/8/parallax-vs-exo/">Parallax&lt;/a>
のような分散AIフレームワークと組み合わせることで、自宅でも本格的なローカルAI推論環境が実現可能になりました。&lt;/p></description></item><item><title>週末ハックから学ぶ「LLM Council」- 複数AIモデルの集合知を活用する新しいアプローチ</title><link>https://blog.tumf.dev/posts/diary/2025/12/14/llm-council-weekend-hack/</link><pubDate>Sun, 14 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/14/llm-council-weekend-hack/</guid><description>&lt;p>&lt;a href="https://github.com/karpathy" target="_blank" rel="noopener noreferrer">Andrej Karpathy&lt;/a>
氏が週末に&amp;quot;vibe code&amp;quot;（勢いでコーディング）したプロジェクト「&lt;a href="https://github.com/karpathy/llm-council" target="_blank" rel="noopener noreferrer">LLM Council&lt;/a>
」が面白かったので紹介します。&lt;/p>
&lt;p>これは、複数の大規模言語モデル（LLM）に同じ質問を投げ、お互いの回答を匿名で評価させ、最終的に議長役のLLMが統合回答を生成するという、&lt;strong>合議制の意思決定システム&lt;/strong>です。&lt;/p>
&lt;p>単一のLLMに頼るのは、バイアスや幻覚（ハルシネーション）のリスクがあります。複数モデルの「多様な視点」を組み合わせることで、より信頼性の高い回答を得られる――そんな実験的アプローチを、シンプルなコードで実装した点が興味深いプロジェクトです。&lt;/p></description></item><item><title>2026年 TypeScriptのビルドがめちゃ速くなる予定</title><link>https://blog.tumf.dev/posts/diary/2025/12/13/typescript-7-go-native-port/</link><pubDate>Sat, 13 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/13/typescript-7-go-native-port/</guid><description>&lt;p>&lt;a href="https://devblogs.microsoft.com/typescript/progress-on-typescript-7-december-2025/" target="_blank" rel="noopener noreferrer">TypeScript 7.0&lt;/a>
が2026年初頭にリリース予定で、最大の変化は&lt;strong>ビルドが最大10倍速くなる&lt;/strong>ことです。実装言語がJavaScriptから&lt;a href="https://blog.tumf.dev/tags/golang/">Go言語&lt;/a>
に変わり、大規模プロジェクトでの開発体験が劇的に改善されます。&lt;/p>
&lt;p>ReactやNext.jsで数百〜数千ファイルのプロジェクトを開発している方には朗報です。本記事では、実際のビルド時間の変化、移行時の注意点、今から準備すべきことをまとめます。&lt;/p></description></item><item><title>Ethereum Glamsterdamアップグレード（2026年予定）の概要と主要機能</title><link>https://blog.tumf.dev/posts/diary/2025/12/12/ethereum-glamsterdam-upgrade-2026/</link><pubDate>Fri, 12 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/12/ethereum-glamsterdam-upgrade-2026/</guid><description>&lt;p>2025年12月の&lt;a href="https://blog.tumf.dev/posts/diary/2025/12/6/ethereum-fusaka-eip7951-passkey-wallet/">Fusakaアップグレード&lt;/a>
に続き、&lt;a href="https://ethereum.org/" target="_blank" rel="noopener noreferrer">Ethereum&lt;/a>
は2026年前半に次期メジャーアップグレード「Glamsterdam」を予定しています。本記事では、Glamsterdamアップグレードの主要機能と、それがEthereumエコシステムにもたらす影響について解説します。&lt;/p></description></item><item><title>Bucketeer：オープンソースで実現する高度なフィーチャーフラグ・A/Bテストプラットフォーム</title><link>https://blog.tumf.dev/posts/diary/2025/12/11/bucketeer-feature-flag-platform/</link><pubDate>Thu, 11 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/11/bucketeer-feature-flag-platform/</guid><description>&lt;p>フィーチャーフラグ（Feature Flag）は、デプロイとリリースを分離し、リスクを最小化しながら機能を段階的にリリースするための強力なツールです。しかし、既存のSaaSソリューション（&lt;a href="https://launchdarkly.com/" target="_blank" rel="noopener noreferrer">LaunchDarkly&lt;/a>
、&lt;a href="https://www.split.io/" target="_blank" rel="noopener noreferrer">Split.io&lt;/a>
、&lt;a href="https://www.optimizely.com/" target="_blank" rel="noopener noreferrer">Optimizely&lt;/a>
など）は高額な月額料金（月数十万円〜）や評価回数の制限があり、大規模なプロジェクトでは導入が難しいケースも少なくありません。&lt;/p>
&lt;p>そんな課題を解決するのが、今回紹介する &lt;a href="https://bucketeer.io/" target="_blank" rel="noopener noreferrer">Bucketeer&lt;/a>
 です。これは&lt;a href="https://www.cyberagent.co.jp/" target="_blank" rel="noopener noreferrer">株式会社サイバーエージェント&lt;/a>
が開発したオープンソースのフィーチャーフラグ・A/Bテストプラットフォームで、セルフホスティングによる完全なデータコントロールと、エンタープライズグレードの機能を組み合わせています。&lt;/p></description></item><item><title>AIブラウザの脆弱性: メール経由でGoogle Driveを全削除する攻撃手法</title><link>https://blog.tumf.dev/posts/diary/2025/12/10/ai-browser-zero-click-drive-wiper-attack/</link><pubDate>Wed, 10 Dec 2025 15:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/10/ai-browser-zero-click-drive-wiper-attack/</guid><description>&lt;p>AIエージェント機能を持つブラウザに、新たなセキュリティリスクが発見されました。攻撃者が細工したメールを送信するだけで、ユーザーのGoogle Driveのファイルを全削除できる「Google Drive Wiper」という攻撃手法が、2025年12月にセキュリティ研究者によって報告されています。&lt;/p>
&lt;p>本記事では、この攻撃の仕組みと、なぜ従来のセキュリティ対策では防げないのか、そして対策方法について解説します。&lt;/p></description></item><item><title>「React2Shell」は偶然ではない：サーバーコンポーネント時代のセキュリティ設計を問い直す</title><link>https://blog.tumf.dev/posts/diary/2025/12/10/react2shell-security-vulnerability/</link><pubDate>Wed, 10 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/10/react2shell-security-vulnerability/</guid><description>&lt;p>&lt;a href="https://react.dev/" target="_blank" rel="noopener noreferrer">React&lt;/a>
のサーバーコンポーネント（React Server Components、RSC）で、リモートコード実行（RCE）を可能にする重大な脆弱性「React2Shell」が発見されました。この脆弱性は単なるバグではなく、クライアントサイドとサーバーサイドの境界を曖昧にする現代のフレームワーク設計が抱える根本的な問題を浮き彫りにしています。本記事では、React2Shell（&lt;a href="https://nvd.nist.gov/vuln/detail/CVE-2025-55182" target="_blank" rel="noopener noreferrer">CVE-2025-55182&lt;/a>
）の技術的詳細と、サーバーコンポーネント時代のセキュリティ設計について考察します。&lt;/p></description></item><item><title>Claude Code で GA4 にアクセスする - Google Analytics MCP Server の活用</title><link>https://blog.tumf.dev/posts/diary/2025/12/9/claude-code-google-analytics-mcp/</link><pubDate>Tue, 09 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/9/claude-code-google-analytics-mcp/</guid><description>&lt;p>Google Analytics のデータ分析、普段どのように行っていますか？Web UIでの操作も便利ですが、LLM（大規模言語モデル）を使って自然言語でデータを問い合わせできたら、さらに効率的になるかもしれません。&lt;/p>
&lt;p>Google から公式に提供されている &lt;a href="https://github.com/googleanalytics/google-analytics-mcp" target="_blank" rel="noopener noreferrer">Google Analytics MCP Server&lt;/a>
 を使えば、この課題を解決できます。Claude Code から直接 Google Analytics 4（GA4）のデータにアクセスできるようになります。この記事では、その導入方法と基本的な使い方について解説します。&lt;/p>
&lt;p>MCP Server の基本的な接続方法を先に掴みたい場合は、&lt;a href="https://blog.tumf.dev/posts/diary/2026/2/10/qmd-obsidian-claude-code-mcp/">Claude CodeでObsidianを高速検索: qmd MCPサーバーの設定と活用&lt;/a>
 から読むと全体像を把握しやすいです。ログ分析まで広げたい場合は、&lt;a href="https://blog.tumf.dev/posts/diary/2025/3/13/local-grafana-loki-mcp-cursor/">Grafana Loki MCP Server設定ガイド: CursorでログをAI分析する&lt;/a>
 も参考になります。&lt;/p></description></item><item><title>Parallax：分散AIクラスター新星、exoとの違いとは？</title><link>https://blog.tumf.dev/posts/diary/2025/12/8/parallax-vs-exo/</link><pubDate>Mon, 08 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/8/parallax-vs-exo/</guid><description>&lt;p>2025年10月にProduct Huntで1位を獲得した&lt;a href="https://github.com/GradientHQ/parallax" target="_blank" rel="noopener noreferrer">Parallax&lt;/a>
が、分散AIクラスター界隈で注目を集めています。以前当ブログで紹介した&lt;a href="https://blog.tumf.dev/posts/diary/2025/1/4/exo-first-impression/">exo&lt;/a>
と同じコンセプトを持ちながら、異なるアプローチを取っているこのツールについて、両者の違いを中心に紹介します。&lt;/p></description></item><item><title>Gitの黒歴史を隠蔽する：履歴書き換えツールまとめ</title><link>https://blog.tumf.dev/posts/diary/2025/12/7/git-history-rewrite-tools/</link><pubDate>Sun, 07 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/7/git-history-rewrite-tools/</guid><description>&lt;p>昨日紹介した&lt;a href="https://blog.tumf.dev/posts/diary/2025/12/5/git-absorb-introduction/">git-absorb&lt;/a>
は、変更を適切なコミットに自動的に吸収する便利なツールでした。しかし、開発の現場では、それ以外にもさまざまな「黒歴史」を隠蔽したい場面があります。&lt;/p>
&lt;p>恥ずかしいコミットメッセージ、デバッグ用のprint文、うっかりコミットしてしまったパスワード、意味のない細かいコミットの乱立&amp;hellip;。こうした「見せたくない履歴」を綺麗に整理するためのツールと手法をまとめてみました。&lt;/p>
&lt;p>この記事では、Gitの履歴書き換え系ツールの使い分けと、それぞれのユースケースについて解説します。&lt;/p></description></item><item><title>Ethereum Fusaka アップデート：EIP-7951 によるパスキーウォレットの実現</title><link>https://blog.tumf.dev/posts/diary/2025/12/6/ethereum-fusaka-eip7951-passkey-wallet/</link><pubDate>Sat, 06 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/6/ethereum-fusaka-eip7951-passkey-wallet/</guid><description>&lt;p>Ethereum は 2025年のメジャーアップデート「Fusaka（フサカ）」において、ウォレットのユーザー体験を根本的に変える可能性のある技術を導入します。その中核となるのが EIP-7951 です。これにより、スマートフォンをハードウェアウォレットとして利用し、Face ID や Touch ID といった生体認証でトランザクションに署名できるようになります。&lt;/p>
&lt;p>この記事では、EIP-7951 がどのようにしてスマートフォンのセキュリティ機能を活用し、従来のウォレットとは異なる新しいセキュリティモデルを実現するのかを解説します。&lt;/p></description></item><item><title>git-absorb: 変更を自動的に適切なコミットに吸収する</title><link>https://blog.tumf.dev/posts/diary/2025/12/5/git-absorb-introduction/</link><pubDate>Fri, 05 Dec 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/12/5/git-absorb-introduction/</guid><description>&lt;p>プルリクエストでレビューを受けた後、「このtypoを修正してください」「この部分のロジックを改善してください」といった指摘に対応する際、どのコミットに修正を含めるべきか判断に迷うことはありませんか？&lt;/p>
&lt;p>従来は&lt;code>git commit --fixup&lt;/code>と&lt;code>git rebase --autosquash&lt;/code>を使う方法がありますが、どのコミットに対するfixupなのかを手動で指定する必要があり、複数のコミットにまたがる修正を行う場合は特に手間がかかります。&lt;/p>
&lt;p>&lt;code>git-absorb&lt;/code>は、この面倒な作業を自動化してくれるツールです。変更内容を解析し、どのコミットを修正するものなのかを自動的に判定して、適切なコミットに変更を吸収（absorb）してくれます。&lt;/p>
&lt;p>この記事では、&lt;code>git-absorb&lt;/code>の基本的な使い方と、実際の開発フローでの活用方法について解説します。&lt;/p></description></item><item><title>git worktreeで実現するVibe Coding並列開発環境</title><link>https://blog.tumf.dev/posts/diary/2025/10/29/wt-vibe-coding/</link><pubDate>Wed, 29 Oct 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/10/29/wt-vibe-coding/</guid><description>&lt;p>AIに「認証機能を実装して」と指示している最中に、緊急のバグ修正依頼が来た。こんな時、どうしていますか？本記事では、Git Worktree管理ツール &lt;code>wt&lt;/code> を使って、複数のAIコーディングセッションを並列で進める実践的な方法を紹介します。&lt;/p></description></item><item><title>one-off-docker-runner volume host bindアップデート</title><link>https://blog.tumf.dev/posts/diary/2025/8/12/one-off-docker-runner-volume-host-bind-update/</link><pubDate>Tue, 12 Aug 2025 00:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/8/12/one-off-docker-runner-volume-host-bind-update/</guid><description>&lt;p>&lt;a href="https://blog.tumf.dev/posts/diary/2025/1/8/one-off-docker-runner/" target="_blank" rel="noopener noreferrer">以前の記事&lt;/a>
 で紹介した one-off-docker-runner に、&lt;code>volumes&lt;/code> の「host bind」機能が追加・改善されました。本記事では、Run API の正確な JSON リクエスト形式、各パラメータの意味、注意点をまとめます。この記事だけでコピペ再現できます。&lt;/p></description></item><item><title>dotenvx: 環境変数管理を快適にするツール</title><link>https://blog.tumf.dev/posts/diary/2025/5/22/dotenvx-intro/</link><pubDate>Thu, 22 May 2025 10:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/5/22/dotenvx-intro/</guid><description>&lt;p>環境変数管理ツール「dotenvx」を最近プロジェクトで導入したので、基本機能や使い方、他ツールとの違い、実際の活用シナリオなどをまとめてみます。普段は &lt;code>python-dotenv&lt;/code> や &lt;code>direnv&lt;/code> などを使ってきましたが、dotenvxはCLIの使い勝手やCI/CDとの親和性が高く、個人的にかなり気に入っています。&lt;/p></description></item><item><title>Deno: TypeScriptを手軽に実行する方法</title><link>https://blog.tumf.dev/posts/diary/2025/5/18/deno-typescript-intro/</link><pubDate>Sun, 18 May 2025 00:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/5/18/deno-typescript-intro/</guid><description>&lt;p>Denoを使えばTypeScriptを簡単に実行することができます。
Denoでは、以下のようなTypeScriptスクリプトを直接実行できます。&lt;/p></description></item><item><title>gitcache：大規模リポジトリの操作を高速化するローカルキャッシュツール</title><link>https://blog.tumf.dev/posts/diary/2025/5/8/gitcache/</link><pubDate>Thu, 08 May 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/5/8/gitcache/</guid><description>&lt;p>大規模なGitリポジトリを扱う場合や、同じリポジトリの複数のクローンを作成する場合、ネットワーク帯域幅とディスク容量の消費が問題になることがあります。今回は、これらの問題を解決するための便利なツール「gitcache」を紹介します。&lt;/p>
&lt;h2 id="gitcacheとは">gitcacheとは&lt;/h2>
&lt;p>&lt;a href="https://github.com/seeraven/gitcache" target="_blank" rel="noopener noreferrer">gitcache&lt;/a>
は、Gitリポジトリのローカルキャッシュを提供するツールです。大規模なリポジトリや複数のクローンを扱う際のパフォーマンスを向上させることを目的としています。&lt;/p>
&lt;p>基本的な考え方は、ローカルにベアミラーを作成し、必要に応じて更新して、それを複数のローカルリポジトリのソースとして使用するというものです。&lt;/p></description></item><item><title>Docker: コンテナからホスト上のコマンドを実行する方法</title><link>https://blog.tumf.dev/posts/diary/2025/5/5/run-command-on-host-from-container/</link><pubDate>Mon, 05 May 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/5/5/run-command-on-host-from-container/</guid><description>&lt;p>nsenterコマンドを使ってDockerコンテナからホスト上のコマンドを実行する方法について紹介します。&lt;/p>
&lt;h2 id="nsenter-を使ってホストのネームスペースに入る">nsenter を使ってホストのネームスペースに入る&lt;/h2>
&lt;p>コンテナを特権モードかつホストの PID ネームスペース共有で起動し、nsenter を用いるとホストのルートプロセス（PID 1）のネームスペース内でコマンドを実行できます。&lt;/p>
&lt;div class="highlight">&lt;div class="chroma">
&lt;table class="lntable">&lt;tr>&lt;td class="lntd">
&lt;pre tabindex="0" class="chroma">&lt;code>&lt;span class="lnt">1
&lt;/span>&lt;span class="lnt">2
&lt;/span>&lt;span class="lnt">3
&lt;/span>&lt;span class="lnt">4
&lt;/span>&lt;span class="lnt">5
&lt;/span>&lt;/code>&lt;/pre>&lt;/td>
&lt;td class="lntd">
&lt;pre tabindex="0" class="chroma">&lt;code class="language-shell" data-lang="shell">&lt;span class="line">&lt;span class="cl">docker run -it --rm &lt;span class="se">\
&lt;/span>&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="se">&lt;/span> --privileged &lt;span class="se">\
&lt;/span>&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="se">&lt;/span> --pid host &lt;span class="se">\
&lt;/span>&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="se">&lt;/span> debian:stable-slim &lt;span class="se">\
&lt;/span>&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="cl">&lt;span class="se">&lt;/span> nsenter -t &lt;span class="m">1&lt;/span> -m -u -n -i bash
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/td>&lt;/tr>&lt;/table>
&lt;/div>
&lt;/div>&lt;p>nsenter コマンドは、既存のプロセスが属する名前空間（namespace）内で指定したプログラムを実行するためのコマンドです。オプションで指定したPIDのプロセスが持つマウント、UTS、IPC、ネットワーク、PID、ユーザー、cgroup、timeなどの名前空間に入ります。プログラムを指定しない場合はデフォルトで${SHELL}（通常は/bin/sh）が実行されます。&lt;/p></description></item><item><title>Grafana Loki MCP Server設定ガイド: CursorでログをAI分析する</title><link>https://blog.tumf.dev/posts/diary/2025/3/13/local-grafana-loki-mcp-cursor/</link><pubDate>Thu, 13 Mar 2025 10:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/3/13/local-grafana-loki-mcp-cursor/</guid><description>&lt;p>&lt;code>Grafana Loki MCP&lt;/code> や &lt;code>Cursor MCP 設定&lt;/code> を調べているなら、やりたいことはだいたい次の3つです。&lt;/p>
&lt;ol>
&lt;li>Grafana Loki をローカルで立ち上げる&lt;/li>
&lt;li>MCP Server 経由で Cursor からログを読めるようにする&lt;/li>
&lt;li>ログが見えないときの確認ポイントを押さえる&lt;/li>
&lt;/ol>
&lt;p>この記事では、以下のツールを組み合わせて、ローカル開発環境でのログ管理と問題解決を効率化する方法を紹介します。&lt;/p>
&lt;p>&lt;img 
 src="https://blog.tumf.dev/images/grafana-loki-mcp-cursor/pic.png" 
 alt="over all of grafana loki mcp cursor"
 loading="lazy"
 decoding="async"
/>
&lt;/p>
&lt;ol>
&lt;li>&lt;a href="https://github.com/tumf/local-logs" target="_blank" rel="noopener noreferrer">local-logs&lt;/a>
 - ローカル環境に簡単にGrafana Lokiスタックを構築するツール&lt;/li>
&lt;li>&lt;a href="https://github.com/tumf/grafana-loki-mcp" target="_blank" rel="noopener noreferrer">grafana-loki-mcp&lt;/a>
 - CursorのMCP（Model Context Protocol）にGrafana Lokiを統合するプラグイン&lt;/li>
&lt;li>&lt;a href="https://cursor.sh/" target="_blank" rel="noopener noreferrer">Cursor&lt;/a>
 - AIを活用したコーディング支援IDE&lt;/li>
&lt;/ol>
&lt;p>これらを組み合わせることで、開発中のアプリケーションのログをリアルタイムで収集・分析し、CursorのAIエージェントがログデータを基に問題解決を支援する環境を構築できます。&lt;/p>
&lt;p>先に結論を書くと、&lt;code>local-logs&lt;/code> で Loki を起動し、Grafana API キーを作成し、Cursor の MCP に &lt;code>uvx grafana-loki-mcp -u http://localhost:9020 -k {Grafana API Key}&lt;/code> を登録すれば最短で試せます。&lt;/p></description></item><item><title>Mac ホスト名の設定と確認方法: HostName/LocalHostName/ComputerNameの違い</title><link>https://blog.tumf.dev/posts/diary/2025/1/10/mac-hostnames/</link><pubDate>Fri, 10 Jan 2025 00:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/1/10/mac-hostnames/</guid><description>&lt;p>奇妙なことにMacOSには3種類のホスト名が存在します。それぞれ役割や設定方法が異なるため、混乱することもあるでしょう。
このブログでは、MacOSにおける3種類のホスト名の違いと設定方法、そして &lt;code>hostname&lt;/code> コマンドによる一時的な変更手順について解説します。&lt;/p>
&lt;p>&lt;strong>結論&lt;/strong>: ホスト名を変更するときには &lt;code>HostName&lt;/code> ・ &lt;code>ComputerName&lt;/code> ・ &lt;code>LocalHostName&lt;/code> を&lt;em>すべて&lt;/em>変更しましょう。&lt;/p></description></item><item><title>AIによるスペックテストの変更をガードする方法</title><link>https://blog.tumf.dev/posts/diary/2025/1/9/python-guard-spec-testcases/</link><pubDate>Thu, 09 Jan 2025 00:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/1/9/python-guard-spec-testcases/</guid><description>&lt;p>テスト駆動開発(TDD)では、顧客の分析された顧客の要求仕様をテストケースとして初期段階に完成させますが、
開発者やAIがこのテストケースを変更してしまってはTDDの意味がありません。&lt;/p>
&lt;p>本稿では、Pythonの &lt;code>pytest&lt;/code> を使ってテストを書いている中で、顧客レビュー済みの&lt;strong>スペックテスト&lt;/strong>（仕様テスト）を開発者が変更してしまうのを防ぐためのアイデアをご紹介いたします。&lt;/p></description></item><item><title>PgBouncer: 高可用性構成(HA)の実装方法</title><link>https://blog.tumf.dev/posts/diary/2025/1/7/pgbouncer-ha/</link><pubDate>Tue, 07 Jan 2025 00:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/1/7/pgbouncer-ha/</guid><description>&lt;p>PostgreSQL環境で&lt;a href="https://www.pgbouncer.org/" target="_blank" rel="noopener noreferrer">PgBouncer&lt;/a>
を高可用性構成で実装する際の考え方を解説します。バックエンドのPostgreSQL自体のHA構成は考慮せず、あくまでPgBouncer側のみを高可用性化する方法を簡単な構成例とあわせて解説します。&lt;/p></description></item><item><title>GitHub Actions cronの使い方: 定期実行・スケジュール設定完全ガイド</title><link>https://blog.tumf.dev/posts/diary/2025/1/6/github-actions-as-cron/</link><pubDate>Mon, 06 Jan 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/1/6/github-actions-as-cron/</guid><description>&lt;p>GitHub Actionsは、リポジトリのコードを基盤にCI/CDタスクを自動化するための強力なツールです。その中でも &lt;code>cron&lt;/code> スケジュールを利用することで、特定のタイミングで定期的にジョブを実行できます。本記事では、GitHub Actionsを使ってcronタスクを設定する方法、利点と欠点、さらに具体的な利用例について解説します。&lt;/p></description></item><item><title>uv add/remove/syncの使い方: Pythonパッケージ管理を完全理解</title><link>https://blog.tumf.dev/posts/diary/2025/1/5/python-uv-subcommands/</link><pubDate>Sun, 05 Jan 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/1/5/python-uv-subcommands/</guid><description>&lt;p>最近Python のプロジェクト管理ツールである &lt;code>uv&lt;/code> を使い始めました。&lt;/p>
&lt;p>そのサブコマンドは一見シンプルに見えますが、似たような機能に見えるコマンドがあるため
「どのコマンドを使えばいいの？」と戸惑うことがあります。
これは、 &lt;code>uv&lt;/code> のサブコマンドに「低レベルの機能」と「高レベルのラッパー」が混在しているためです。&lt;/p>
&lt;p>この記事では、 &lt;code>uv&lt;/code> のサブコマンドを低レベルの機能と高レベルのラッパーに分類し、それぞれの役割や使いどころを整理してみます。特に、普段遣いで便利な高レベルのラッパーに注目し、効率的な使い方を解説します。&lt;/p></description></item><item><title>exo: 分散AIクラスターを2台のMacBookで構築する</title><link>https://blog.tumf.dev/posts/diary/2025/1/4/exo-first-impression/</link><pubDate>Sat, 04 Jan 2025 00:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/1/4/exo-first-impression/</guid><description>&lt;p>最近注目を集めているオープンソースの分散AIクラスターソフトウェア &lt;code>exo&lt;/code> を、手元のMacBook 2台を使って試してみました。本記事では、exoの概要、インストール方法、設定、そして実際の使用感について詳しく紹介します。&lt;/p></description></item><item><title>Pythonの非同期フレームワーク比較：asyncio, Trio, AnyIO</title><link>https://blog.tumf.dev/posts/diary/2025/1/3/python-async-frameworks/</link><pubDate>Fri, 03 Jan 2025 07:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/1/3/python-async-frameworks/</guid><description>&lt;p>今日は、Pythonの非同期プログラミングフレームワークとしてよく出てくる、
&lt;a href="https://docs.python.org/3/library/asyncio.html" target="_blank" rel="noopener noreferrer">asyncio&lt;/a>
, &lt;a href="https://Trio.readthedocs.io/" target="_blank" rel="noopener noreferrer">Torio&lt;/a>
, &lt;a href="https://anyio.readthedocs.io/" target="_blank" rel="noopener noreferrer">AnyIO&lt;/a>

について、どれ使えばいい問題をサクッと解決します。&lt;/p></description></item><item><title>SQLAlchemyでmypy型チェックエラーに対処する方法</title><link>https://blog.tumf.dev/posts/diary/2025/1/1/python-sqlalchemy-mypy/</link><pubDate>Wed, 01 Jan 2025 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/1/1/python-sqlalchemy-mypy/</guid><description>&lt;p>SQLAlchemyはPythonのデータベース操作を強力に支援してくれるライブラリですが、mypyなどの型チェックツールと組み合わせると問題が発生することがあります。この記事では、特にselect.where句で型エラーが発生するケースについて、再現例と解決策を詳しく紹介します。最近この現象でドハマリしたので備忘録です。&lt;/p></description></item><item><title>OpenCommit: Ollama + Llama3でローカルAIコミットメッセージ生成</title><link>https://blog.tumf.dev/posts/diary/2024/5/3/2024-5-3/</link><pubDate>Fri, 03 May 2024 10:00:00 +0700</pubDate><guid>https://blog.tumf.dev/posts/diary/2024/5/3/2024-5-3/</guid><description>&lt;p>gitのコミットログを自動で生成してくれる&lt;a href="https://github.com/di-sukharev/opencommit" target="_blank" rel="noopener noreferrer">OpenCommit&lt;/a>
を使い始めました。非常に便利です。&lt;/p>
&lt;p>OpenCommitはデフォルトで &lt;code>GPT-3.5 Turbo&lt;/code> に対応しており、さらに &lt;code>GPT-4&lt;/code> や &lt;code>GPT-4 Turbo&lt;/code> といった高性能モデルも利用可能です。
高性能でとても便利なのですが、これらのモデルはインターネットに繋ぎOpenAI社のサーバに繋ぐ必要があるため、オフライン環境、例えば飛行機内での作業ができません。&lt;/p></description></item><item><title>シャミアの秘密分散を試してみる</title><link>https://blog.tumf.dev/posts/diary/2023/4/2023-4-24/</link><pubDate>Mon, 24 Apr 2023 00:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2023/4/2023-4-24/</guid><description>&lt;p>&lt;a href="https://ja.wikipedia.org/wiki/%E7%A7%98%E5%AF%86%E5%88%86%E6%95%A3" target="_blank" rel="noopener noreferrer">シャミアの秘密分散法&lt;/a>
(Shamir&amp;rsquo;s secret sharing)を、&lt;code>ethers.js&lt;/code>を使用して試してみます。以下は、シャミアの秘密分散法を実装するためのコード例です。&lt;/p></description></item><item><title>HugoのブログにでMermaidの図を埋め込む</title><link>https://blog.tumf.dev/posts/diary/2023/4/2023-4-23/</link><pubDate>Sun, 23 Apr 2023 00:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2023/4/2023-4-23/</guid><description>&lt;p>このブログは&lt;a href="https://gohugo.io/" target="_blank" rel="noopener noreferrer">Hugo&lt;/a>
というブログフレームワークを使っていますが、ここに&lt;a href="https://mermaid.js.org/" target="_blank" rel="noopener noreferrer">Mermaid&lt;/a>
で図を簡単に埋め込む方法をご紹介します。これによって、プログラムのフローチャートやシーケンス図などを簡単に生成できるようになります。&lt;/p></description></item><item><title>EthereumのDeployerを特定する</title><link>https://blog.tumf.dev/posts/diary/2023/4/2023-4-20/</link><pubDate>Thu, 20 Apr 2023 00:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2023/4/2023-4-20/</guid><description>&lt;p>Web3サービスでdeployerを調べる簡単な方法がないか実験してみました。deployerは、スマートコントラクトをデプロイした人のアドレスです。本記事では、&lt;a href="https://etherscan.io" target="_blank" rel="noopener noreferrer">Etherscan&lt;/a>
のAPIを使用して、コントラクトアドレスからdeployerを調べる方法を紹介します。&lt;/p></description></item><item><title>PythonでVOICEBOXを使ってずんだもんに喋らせてみよう</title><link>https://blog.tumf.dev/posts/diary/2023/4/2023-4-19/</link><pubDate>Wed, 19 Apr 2023 00:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2023/4/2023-4-19/</guid><description>&lt;p>今日はPythonを使って、YouTubeでよく見かける人気キャラクター「ずんだもん」に喋ってもらいましょう。この記事では、&lt;a href="https://voicevox.hiroshiba.jp/" target="_blank" rel="noopener noreferrer">VOICEBOX&lt;/a>
というすごいソフトウェアを使って、簡単にずんだもんの声を再現する方法をご紹介します。&lt;/p></description></item><item><title>チャットアプリの会話コンテキストリデューサー:Motörhead</title><link>https://blog.tumf.dev/posts/diary/2023/4/2023-4-18/</link><pubDate>Tue, 18 Apr 2023 00:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2023/4/2023-4-18/</guid><description>&lt;p>AI を活用したチャットアプリの開発では、会話のコンテキストをどのようにプロンプトに含めるかが重要な課題です。
単純なチャットアプリでは、例えば直近 5 件分の会話をプロンプトに含めて AI の返答を自然にしたりします。&lt;/p>
&lt;p>しかし、会話の中には文脈に関係ない情報が多く含まれていることがあります。これを効率的に削減するために、文脈の「要約」を AI で行い、それをプロンプトに含める方法があります。&lt;/p>
&lt;p>&lt;a href="https://github.com/getmetal/motorhead" target="_blank" rel="noopener noreferrer">Motörhead&lt;/a>
は、こういったチャットアプリの実装を代わりに行ってくれるツールです。&lt;/p></description></item><item><title>Lokiのデータを一定時間後に削除する</title><link>https://blog.tumf.dev/posts/diary/2023/4/2023-4-17/</link><pubDate>Mon, 17 Apr 2023 00:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2023/4/2023-4-17/</guid><description>&lt;p>&lt;a href="https://grafana.com/oss/loki/" target="_blank" rel="noopener noreferrer">Grafana Loki&lt;/a>
はログ管理システムであり、大量のログデータを効果的に管理するために使用されます。しかし、Loki はログデータが膨大になるとストレージ領域を圧迫する可能性があります。そこで、一定期間ごとに Loki の古いログデータを削除する必要があります。本記事では、Bash シェルスクリプトを使用して Loki のログデータを削除する方法を説明します。&lt;/p></description></item><item><title>GnuPG: 公開鍵の有効期限を延長する方法</title><link>https://blog.tumf.dev/posts/diary/2023/2/2023-2-5/</link><pubDate>Sun, 05 Feb 2023 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2023/2/2023-2-5/</guid><description>&lt;p>&lt;a href="https://gnupg.org/" target="_blank" rel="noopener noreferrer">GnuPG&lt;/a>
は、暗号化、署名、認証に使用するための公開鍵暗号システムです。GnuPGでは、公開鍵には有効期限が設定されており、その期間が過ぎるとその鍵は使用できなくなります。有効期限が近づいている場合や、期限切れになっている場合は、その鍵を延長する必要があります。この記事では、GnuPGでキーの有効期限を延長する方法について説明します。&lt;/p></description></item><item><title>グラフノードのスケールアウト</title><link>https://blog.tumf.dev/posts/diary/2022/5/2022-5-3/</link><pubDate>Tue, 03 May 2022 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2022/5/2022-5-3/</guid><description>&lt;p>&lt;img 
 src="https://i.imgur.com/gflC4nE.png" 
 alt="グラフノードのスケールアウトの画像"
 loading="lazy"
 decoding="async"
/>
&lt;/p>
&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/easy-setup-scaling-out-of-your-graph-node-32e2">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>何らかの理由により&lt;a href="https://thegraph.com/en/" target="_blank" rel="noopener noreferrer">The Graph&lt;/a>
等のhosted-serviceを使わずに自分で&lt;a href="https://github.com/graphprotocol/graph-node" target="_blank" rel="noopener noreferrer">graph-node&lt;/a>
を建てる場合、グラフノードのスケールアウトも正しく考慮する必要があります。スケールアウトできる構成を組まないと、Web3クライアントからリクエストが504(Gateway Timeout)になってしまう事態が頻発します。本稿では簡単に実現できるグラフノードのスケールアウトの方法をご紹介します。&lt;/p></description></item><item><title>Solidityオプティマイザはストレージ変数の変更を避けてくれるのか?</title><link>https://blog.tumf.dev/posts/diary/2022/2/2022-2-14/</link><pubDate>Mon, 14 Feb 2022 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2022/2/2022-2-14/</guid><description>&lt;p align="right">&lt;em>&lt;a href="https://dev.to/tumf/does-solidity-optimizer-avoid-changing-storage-variables-5h9h">English version&lt;/a>&lt;/em>&lt;/p>
&lt;p>ブロックチェーン上のスマートコントラクトを開発するに当たって実行コストである「ガス代」を削減することは重要な事です。&lt;a href="https://mudit.blog/solidity-gas-optimization-tips/" target="_blank" rel="noopener noreferrer">消費Gasを削減するためのいくつかの有名なトリック&lt;/a>
があるのですが、そのうちの一つに「ストレージ変数の変更を避ける(Avoid changing storage data)」というのがあります。&lt;/p>
&lt;p>例えばUniswapV2のスマートコントラクトにはこんな感じで&lt;code>gas savings&lt;/code>のトリックが至る所に施されています。&lt;/p>
&lt;p>&lt;img 
 src="https://i.imgur.com/Ylb0DKg.png" 
 alt="Uniswap/v2-core"
 loading="lazy"
 decoding="async"
/>
&lt;/p>
&lt;p>自分でスマートコントラクトを書いたり、レビューしたりするときにはこの点常に気をつけているのですが、先日ふと「これあまりにも古典的なトリックなので、すでにSolidityのオプティマイザで解決されてるのでは?」と思い、最新のSolidityコンパイラ&lt;code>0.8.11&lt;/code>で検証してみました。&lt;/p></description></item><item><title>16ヶ月間の放浪生活を終えて、タイ・バンコクで再起動中</title><link>https://blog.tumf.dev/posts/diary/2021/12/2021-12-8/</link><pubDate>Wed, 08 Dec 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/12/2021-12-8/</guid><description>&lt;p>&lt;img 
 src="https://i.imgur.com/iVsW6Dz.png" 
 alt="真栄田岬"
 loading="lazy"
 decoding="async"
/>
&lt;/p>
&lt;p>なんとなく事態が緊迫している空気を感じ、コロナ禍のベトナム・ダナンから急遽思い立って帰国したのが2020年の7月でした。この日の翌日からベトナムと日本の定期便が停止となりましたのでギリギリ日本に滑り込んだというタイミングでした。この当時、完全にベトナムに移住していたため日本住むところがなく、またすぐにベトナムに帰るつもりだったので日本で居所を借りずにマンスリーマンションや民泊(AirBnBなど)を利用して日本各地を泊まり歩いていました。この放浪生活が最終的には16ヶ月続きました。&lt;/p></description></item><item><title>ATOK for Macの環境設定</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-28/</link><pubDate>Sun, 28 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-28/</guid><description>&lt;p>今年からこの日記を書き始めて日本語入力と英語入力を切り替える頻度が上がりました。macOSの日本語変換にイラッとする事が多くなり、&lt;a href="https://www.justsystems.com/jp/products/atokmac/" target="_blank" rel="noopener noreferrer">ATOK for Mac&lt;/a>
を使ってみました。今日はATOKを使用した感想を書いてみたいと思います。&lt;/p></description></item><item><title>SyncThingでディレクトリ削除の同期エラー</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-27/</link><pubDate>Sat, 27 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-27/</guid><description>&lt;p>リモートサーバと開発用Macのファイル同期をしている&lt;a href="https://syncthing.net/" target="_blank" rel="noopener noreferrer">SyncThing&lt;/a>
が同期エラーを出していました。&lt;/p>
&lt;p>&lt;img 
 src="https://i.imgur.com/4o8JnEX.png" 
 alt="SyncThingでディレクトリ削除の同期エラーの画像"
 loading="lazy"
 decoding="async"
/>
&lt;/p>
&lt;p>今日はこのエラーの対処をします。&lt;/p></description></item><item><title>sysstatは忘れずに</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-25/</link><pubDate>Thu, 25 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-25/</guid><description>&lt;p>サーバがトラブルを起こして止まった後のトラブルシューティングで気づく、入れ忘れていたパッケージランキングのトップが&lt;code>sysstat&lt;/code>でしょう。&lt;code>sar&lt;/code>と言うコマンドを提供するこのパッケージは以下のようなCPUやメモリなどの使用状況を記録してくれます。&lt;/p>
&lt;p>&lt;img 
 src="https://i.imgur.com/BLw7DDP.png" 
 alt="sysstatは忘れずにの画像"
 loading="lazy"
 decoding="async"
/>
&lt;/p></description></item><item><title>BinanceSmartChainのProof-of-Staked-Authority</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-24/</link><pubDate>Wed, 24 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-24/</guid><description>&lt;p>&lt;a href="https://www.binance.org/en/smartChain" target="_blank" rel="noopener noreferrer">BinanceSmartChain&lt;/a>
(以下、BSC)が凄まじい勢いでトランザクションを増やしています。&lt;a href="https://github.com/ethereum/go-ethereum" target="_blank" rel="noopener noreferrer">go-ethereum&lt;/a>
をベースとし、Ethereumのエコシステムを引き続きつつ、ステークによるコンセンサスアルゴリズムで早く・コストが安いトランザクションを実現しています。実際BSCにトランザクションを流してみると、BitcoinやEthereumメインネットが一世代前のものに見えます。&lt;/p>
&lt;p>当初から言われているとおり、BSCの「早さ安さ」というのはセキュリティとのトレードオフで実現されています。今日は、BSCのコンセンサスアルゴリズムの中核となるProof of Staked Authorityがどんなものか&lt;a href="https://github.com/binance-chain/bsc#proof-of-staked-authority" target="_blank" rel="noopener noreferrer">本家ドキュメント&lt;/a>
から抜粋翻訳してみます。&lt;/p></description></item><item><title>GoogleSpreadSheetにJSONファイルを読み込む</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-23/</link><pubDate>Tue, 23 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-23/</guid><description>&lt;p>&lt;img 
 src="https://i.imgur.com/lhOGeYs.png" 
 alt="GoogleSpreadSheetにJSONファイルを読み込むの画像"
 loading="lazy"
 decoding="async"
/>
&lt;/p>
&lt;p>&lt;a href="https://blog.tumf.dev/posts/diary/2021/2/2021-2-21/">GoogleSpreadSheetにCSVファイルを読み込むスクリプト&lt;/a>
に続いて、今日はネット上に公開されているJSONファイルをGoogleSpreadSheetに取り込んでみます。&lt;/p></description></item><item><title>BitcoinのUTXOの残高を調べる</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-22/</link><pubDate>Mon, 22 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-22/</guid><description>&lt;p>先日、ビットコインのUTXOの一覧から残高を調べたい用途に簡単なスクリプトを書きました。&lt;/p></description></item><item><title>GoogleSpreadSheetにCSVファイルを読み込むスクリプト</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-21/</link><pubDate>Sun, 21 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-21/</guid><description>&lt;p>&lt;img 
 src="https://i.imgur.com/lhOGeYs.png" 
 alt="GoogleSpreadSheetにCSVファイルを読み込むスクリプトの画像"
 loading="lazy"
 decoding="async"
/>
&lt;/p>
&lt;p>ネットからダウンロードしたＣＳＶファイルを、&lt;a href="https://www.google.com/intl/ja_jp/sheets/about/" target="_blank" rel="noopener noreferrer">GoogleSpreadSheet&lt;/a>
に展開するスクリプトをGooglAppsScript(GAS)で書きました。BasicAuthに対応しています。&lt;/p></description></item><item><title>FilecoinクライアントLotusの必要要件</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-20/</link><pubDate>Sat, 20 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-20/</guid><description>&lt;p>&lt;img 
 src="https://i.imgur.com/ibZbW1t.png" 
 alt="lotus"
 loading="lazy"
 decoding="async"
/>
&lt;/p>
&lt;p>&lt;a href="https://github.com/filecoin-project/lotus" target="_blank" rel="noopener noreferrer">Lotus&lt;/a>
 は、&lt;a href="https://filecoin.io" target="_blank" rel="noopener noreferrer">Filecoin&lt;/a>
ネットワーク上でストレージと検索取引を実行できるフル機能のクライアントです。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://docs.filecoin.io/store/lotus/" target="_blank" rel="noopener noreferrer">https://docs.filecoin.io/store/lotus/&lt;/a>
&lt;/li>
&lt;/ul>
&lt;p>今日からははこのLotusをインストールしてみたいと思います。&lt;/p></description></item><item><title>Filecoinのスラッシング(罰金メカニズム)</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-19/</link><pubDate>Fri, 19 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-19/</guid><description>&lt;p>個人的な興味で集中的に&lt;a href="https://docs.filecoin.io/mine/slashing/" target="_blank" rel="noopener noreferrer">Filecoin&lt;/a>
の調査をしています。今日はマイナーに対するペナルティー&lt;strong>スラッシング&lt;/strong>についてのドキュメントを翻訳します。&lt;/p>
&lt;p>ドキュメント: &lt;a href="https://docs.filecoin.io/mine/slashing/" target="_blank" rel="noopener noreferrer">Slashing&lt;/a>
&lt;/p></description></item><item><title>Filecoinのマイニング報酬</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-18/</link><pubDate>Thu, 18 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-18/</guid><description>&lt;p>今日は&lt;a href="https://filecoin.io" target="_blank" rel="noopener noreferrer">Filecoin&lt;/a>
の&lt;a href="https://docs.filecoin.io/mine/mining-rewards/" target="_blank" rel="noopener noreferrer">Mining Rewards&lt;/a>
ドキュメントを読みました。翻訳を掲載します。&lt;/p></description></item><item><title>Filecoinマイニングの3つの種類</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-17/</link><pubDate>Wed, 17 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-17/</guid><description>&lt;p>引き続き&lt;a href="https://filecoin.io" target="_blank" rel="noopener noreferrer">Filecoin&lt;/a>
の勉強をしています。今日はFilecoinマイニングの3つの種類について。公式ドキュメントの、&lt;a href="https://docs.filecoin.io/mine/how-mining-works" target="_blank" rel="noopener noreferrer">How mining work&lt;/a>
を翻訳＆要約してみました。&lt;/p></description></item><item><title>ARCHISSキーボードの導入</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-16/</link><pubDate>Tue, 16 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-16/</guid><description>&lt;p>&lt;a href="https://archisite.co.jp/" target="_blank" rel="noopener noreferrer">ARCHISITE社&lt;/a>
製ARCHISS英語87キーボードを購入しました。RealForceをずっと使ってきましたがなぜか品薄で評判のよさげなキーボードを探した結果本キーボードとなりました。&lt;/p>
&lt;iframe style="width:120px;height:240px;" marginwidth="0" marginheight="0" scrolling="no" frameborder="0" src="//rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&amp;bc1=000000&amp;IS2=1&amp;bg1=FFFFFF&amp;fc1=000000&amp;lc1=0000FF&amp;t=tumf-22&amp;language=ja_JP&amp;o=9&amp;p=8&amp;l=as4&amp;m=amazon&amp;f=ifr&amp;ref=as_ss_li_til&amp;asins=B01M197LU4&amp;linkId=79e64b7ec33a52405c83a37d5994dda0">&lt;/iframe></description></item><item><title>Filecoinマイニングに必要なもの（ざっくり）</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-15/</link><pubDate>Mon, 15 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-15/</guid><description>&lt;p>&lt;a href="https://filecoin.io/" target="_blank" rel="noopener noreferrer">Filecoin&lt;/a>
はマイニングにより採掘可能です。暗号資産の文脈から&lt;code>マイニング&lt;/code>と呼んでいますが、実態としてはネットワークに接続されたストレージを第三者に提供する事です。&lt;a href="https://docs.filecoin.io/mine/hardware-requirements/#general-hardware-requirements" target="_blank" rel="noopener noreferrer">Filecoinのマイニングにはかなり高スペックなマシンが必要とされます&lt;/a>
、ざっくり抜粋すると以下のようになります。&lt;/p></description></item><item><title>IPFSとFilecoin</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-14/</link><pubDate>Sun, 14 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-14/</guid><description>&lt;p>今日は&lt;a href="https://ipfs.io/" target="_blank" rel="noopener noreferrer">IPFS&lt;/a>
というP2P分散ストレージプロトコルについてずっと疑問に思っていたことについて書こうと思います。暗号資産の文脈から&lt;a href="https://coinmarketcap.com/ja/currencies/filecoin/" target="_blank" rel="noopener noreferrer">Filecoin:FIL&lt;/a>
を出した方が通りが良い人もいるかもしれません。私の中でこの2つの関係が不明でした。なぜなら、IPFS自体は完全に無料で利用可能でIPFSを利用していても&lt;code>Filecoin&lt;/code>を要求されることはないからです。&lt;/p>
&lt;p>&lt;img 
 src="https://i.imgur.com/jyXkNuv.png" 
 alt="IPFSデスクトップアプリ"
 loading="lazy"
 decoding="async"
/>
&lt;/p></description></item><item><title>CORSセーフリストリクエストヘッダーに関するトリビア</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-13/</link><pubDate>Sat, 13 Feb 2021 09:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-13/</guid><description>&lt;p>セキュリティに特別な配慮が必要なサーバーサイドアプリケーションは、ブラウザに対して&lt;a href="https://developer.mozilla.org/ja/docs/Web/HTTP/CORS" target="_blank" rel="noopener noreferrer">CORS&lt;/a>
の一部として&lt;code>Access-Control-Allow-Headers&lt;/code>というアドバイスをします。これは、サーバーサイドでクロスオリジンサイトとして安全とアドバイスしたサイトに対し「但し、&lt;code>Access-Control-Allow-Headers&lt;/code>にあるヘッダーに限る」と制限をつけるものです。しかしながらヘッダーの性質上セキュリティに問題なりにくいヘッダについてはわざわざここにリストされていなくてもOKという取り決めがあります。これが&lt;a href="https://developer.mozilla.org/ja/docs/Glossary/CORS-safelisted_request_header" target="_blank" rel="noopener noreferrer">CORSセーフリストリクエストヘッダー&lt;/a>
となります。&lt;/p></description></item><item><title>traefik配下のサービスにCORSを設定する</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-12/</link><pubDate>Fri, 12 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-12/</guid><description>&lt;p>traefik配下のサービスでAPIを提供するときに、ブラウザに対しCORSによるアドバイスを行います。&lt;/p></description></item><item><title>任意の文字列を含んだビットコインアドレスを作成する方法</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-11/</link><pubDate>Thu, 11 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-11/</guid><description>&lt;p>特定の文字列で始まるBitcoinの受け取りアドレスを作るには&lt;code>vanitygen&lt;/code>というソフトウェアを利用します。&lt;/p></description></item><item><title>curlのresolveオプションのポート指定</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-10/</link><pubDate>Wed, 10 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-10/</guid><description>&lt;p>&lt;a href="https://curl.se/" target="_blank" rel="noopener noreferrer">curl&lt;/a>
を使ってWebの接続を試したいときに&lt;code>--resolve&lt;/code>というオプションを使ってホストの名前解決を上書きできます。例えばローカルサーバ&lt;code>localhost:3000&lt;/code>を
&lt;code>example.com&lt;/code>でアクセスしたいときには以下のようにします&lt;/p>
&lt;pre tabindex="0">&lt;code>curl -i --resolv example.com:3000:127.0.0.1 http://example.com:3000
&lt;/code>&lt;/pre>&lt;p>ふと、このresolveオプション&lt;code>example.com:3000:127.0.0.1&lt;/code>の3000番ポートの部分って何のためにあるんだろう？って思いましたので調べてみました。&lt;/p></description></item><item><title>n8nのSlackノードへのプルリクエスト</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-9/</link><pubDate>Tue, 09 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-9/</guid><description>&lt;p>&lt;img 
 src="https://blog.tumf.dev/images/tags/n8n.png" 
 alt="n8nのSlackノードへのプルリクエストの画像"
 loading="lazy"
 decoding="async"
/>
&lt;/p>
&lt;p>n8n(Nodenamtion)でSlackを使ったアプリを作っていてどうしても欲しい機能があったので追加してのプルリクエストを投稿しました。&lt;/p>
&lt;p>&lt;a href="https://github.com/n8n-io/n8n/pull/1366" target="_blank" rel="noopener noreferrer">Add chat.getPermalink interface in Slack Nodes. #1366&lt;/a>
&lt;/p>
&lt;p>現在は、マージされリリースされています。
このPRは、Slackのメッセージに対しパーマリンクを得るためのAPI&lt;a href="https://api.slack.com/methods/chat.getPermalink" target="_blank" rel="noopener noreferrer">chat.getPermalink&lt;/a>
を呼び出すためのものです。&lt;/p></description></item><item><title>Growiでwikiサイトを立ち上げる</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-8/</link><pubDate>Mon, 08 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-8/</guid><description>&lt;p>&lt;a href="https://growi.org/" target="_blank" rel="noopener noreferrer">Growi&lt;/a>
という優れたwikiエンジンでwikiサイト(&lt;a href="https://wiki.tumf.dev/" target="_blank" rel="noopener noreferrer">wiki.tumf.dev&lt;/a>
)を立ち上げてみます。Growiはmarkdownで記述でき、かなり高機能で別のところで愛用しています。&lt;/p></description></item><item><title>ランダムな文字列を生成する</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-7/</link><pubDate>Sun, 07 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-7/</guid><description>&lt;p>シェルからパスワードなどを簡単に生成したい時に以下のようにします&lt;/p></description></item><item><title>Vimのバッファの表示状態を自動で保存する</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-6/</link><pubDate>Sat, 06 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-6/</guid><description>&lt;p>私は、メインのエディタとしてVimクローンの&lt;a href="https://neovim.io/" target="_blank" rel="noopener noreferrer">neovim&lt;/a>
を使っています。折りたたみ(fold)を覚えてそこそこ大きなソースコードの編集が楽になりました。しかしながら、nvim起動の度に折りたたみ状況が解除されて手間だったので、バッファ状態保存の方法を調べたら以下の方法に行き当たりました。&lt;/p></description></item><item><title>ものぐさを極めた伝統的なシェルスクリプトssh-argv0</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-5/</link><pubDate>Fri, 05 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-5/</guid><description>&lt;p>今日は、&lt;code>ssh-argv0&lt;/code>という、ものぐさを極めた伝統的なシェルスクリプトを紹介します。&lt;/p>
&lt;div class="highlight">&lt;div class="chroma">
&lt;table class="lntable">&lt;tr>&lt;td class="lntd">
&lt;pre tabindex="0" class="chroma">&lt;code>&lt;span class="lnt">1
&lt;/span>&lt;/code>&lt;/pre>&lt;/td>
&lt;td class="lntd">
&lt;pre tabindex="0" class="chroma">&lt;code class="language-shell" data-lang="shell">&lt;span class="line">&lt;span class="cl">$ ssh example.com
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/td>&lt;/tr>&lt;/table>
&lt;/div>
&lt;/div>&lt;p>とするのを&lt;/p>
&lt;div class="highlight">&lt;div class="chroma">
&lt;table class="lntable">&lt;tr>&lt;td class="lntd">
&lt;pre tabindex="0" class="chroma">&lt;code>&lt;span class="lnt">1
&lt;/span>&lt;/code>&lt;/pre>&lt;/td>
&lt;td class="lntd">
&lt;pre tabindex="0" class="chroma">&lt;code class="language-shell" data-lang="shell">&lt;span class="line">&lt;span class="cl">$ example.com
&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/td>&lt;/tr>&lt;/table>
&lt;/div>
&lt;/div>&lt;p>と&lt;code>ssh &lt;/code>の部分省略できるスクリプトです。これだけですが😅&lt;/p></description></item><item><title>CloudRunでSinatra動かしてみた</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-4/</link><pubDate>Thu, 04 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-4/</guid><description>&lt;p>&lt;a href="https://console.cloud.google.com/" target="_blank" rel="noopener noreferrer">GoogleCloudPlatform&lt;/a>
(以下GCP)には&lt;a href="https://cloud.google.com/functions" target="_blank" rel="noopener noreferrer">CloudFunctions&lt;/a>
と&lt;a href="https://cloud.google.com/run" target="_blank" rel="noopener noreferrer">CloudRun&lt;/a>
という2つのサーバレスサービスがあります。簡単にいうとこの2つは動作環境が違います。&lt;code>CloudFunctions&lt;/code>は開発者のコードを固定されたOS環境で動かすためのものであるのに対し、&lt;code>CloudRun&lt;/code>は開発者が持ち込んだDockerコンテナを動かします。どちらを利用するべきか考える順番は&lt;code>CloudFunctions&lt;/code>→&lt;code>CloudRun&lt;/code>です。双方の違いは「&lt;strong>自由と簡単&lt;/strong>」のトレードオフです。&lt;/p>
&lt;p>今回&lt;code>CloudRun&lt;/code>を初めて使ってみましたので記事にしてみました。&lt;/p></description></item><item><title>n8nでImageMagickを使えるようにしてみる</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-3/</link><pubDate>Wed, 03 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-3/</guid><description>&lt;p>&lt;a href="https://n8n.io" target="_blank" rel="noopener noreferrer">n8n&lt;/a>
には&lt;code>EditImage&lt;/code>という画像処理ノードがインテグレーションされていて、簡単な操作ならこれで十分処理ができます。&lt;code>EditImage&lt;/code>は内部で&lt;a href="https://aheckmann.github.io/gm/" target="_blank" rel="noopener noreferrer">GraphicsMagick&lt;/a>
が使われていますが、とある理由から&lt;a href="https://imagemagick.org/" target="_blank" rel="noopener noreferrer">ImageMagick&lt;/a>
を使いたくなり&lt;a href="https://blog.tumf.dev/posts/diary/2021/1/2021-1-22/" target="_blank" rel="noopener noreferrer">shell-jsonrpc&lt;/a>
を使って実装してみました。&lt;code>shell-jsonrpc&lt;/code>は、以前の記事でバイナリデータに対応するようになっています。&lt;/p>
&lt;ul>
&lt;li>&lt;a href="https://blog.tumf.dev/posts/diary/2021/1/2021-1-29/" target="_blank" rel="noopener noreferrer">shell-jsonrpcをバイナリ対応してみた&lt;/a>
&lt;/li>
&lt;/ul></description></item><item><title>内部向けリンクの target=_blankを削除</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-2/</link><pubDate>Tue, 02 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-2/</guid><description>&lt;p>このブログ内のリンクが&lt;code>_blank&lt;/code>だったりそうでなかったりと統一されてないなかったので以下のようなJavascriptで一括修正することにしました。
基本的に&lt;code>target=_blank&lt;/code>が設定されているみたいなので、内部向けリンクについてa要素の&lt;code>target&lt;/code>属性を削除する。&lt;/p></description></item><item><title>n8nでHackMDのメモをGoogleDriveにバックアップする</title><link>https://blog.tumf.dev/posts/diary/2021/2/2021-2-1/</link><pubDate>Mon, 01 Feb 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/2/2021-2-1/</guid><description>&lt;p>今日は以前の記事&lt;a href="https://blog.tumf.dev/posts/diary/2021/1/2021-1-27/" target="_blank" rel="noopener noreferrer">HackMD CLIをJSON-RPC経由で使う&lt;/a>
でで作った&lt;a href="https://github.com/tumf/hackmd-cli-api" target="_blank" rel="noopener noreferrer">hackmd-cli-api&lt;/a>
を&lt;a href="https://n8n.io/" target="_blank" rel="noopener noreferrer">n8n&lt;/a>
に組み込んでHackMDの日次バックアップを実装してみました。&lt;/p>
&lt;p>できあがったのがこちら。
&lt;img 
 src="https://i.imgur.com/UXntD3t.png" 
 alt="Backup HackMD to Google Drive"
 loading="lazy"
 decoding="async"
/>
&lt;/p></description></item><item><title>tmuxをネストして起動しない</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-31/</link><pubDate>Sun, 31 Jan 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-31/</guid><description>&lt;p>リモート環境だけでなくローカル環境でも tmux を使っていて、リモート環境でうっかり tmux を起動するとローカルの tmux の中に入れ子でリモートの tmux が起動します。この状態だとすべての tmux がプレフィクスが外側(ローカル側)に捉えれてしまって内側(リモート側)の tmux が制御不能となります。これを防ぐために、&lt;a href="https://takegue.hatenablog.com/entry/2015/01/30/021846" target="_blank" rel="noopener noreferrer">内側の tmux プレフィクスのキーバインドを変えるという方法&lt;/a>
もあるのですが、操作が複雑で誤動作も多くなるのでもういっそ tmux から tmux を起動した場合は起動を抑制するようにしようと思います。&lt;/p></description></item><item><title>traefik配下のサービスにBasic認証を設定する</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-30/</link><pubDate>Sat, 30 Jan 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-30/</guid><description>&lt;p>&lt;a href="">traefik&lt;/a>
で自分で建てたウェブサービスにパスワードを設定する方法を紹介します。&lt;a href="https://blog.tumf.dev/posts/diary/2021/1/2021-1-16/" target="_blank" rel="noopener noreferrer">以前の記事(1つのサーバにたくさんのWebサービスを詰め込む方法)&lt;/a>
で使った&lt;code>whoami&lt;/code>サービスを例に設定方法をメモします。&lt;/p></description></item><item><title>shell-jsonrpcをバイナリ対応してみた</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-29/</link><pubDate>Fri, 29 Jan 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-29/</guid><description>&lt;p>以前の記事、&lt;a href="https://blog.tumf.dev/posts/diary/2021/1/2021-1-22/" target="_blank" rel="noopener noreferrer">shellコマンドをJSON-RPC経由で実行する
&lt;/a>
にて作った&lt;a href="https://github.com/tumf/shell-jsonrpc" target="_blank" rel="noopener noreferrer">shell-jsonrpc&lt;/a>
ですが、ふとバイナリファイルの扱いがどうなっているか不安になって調べてみました→だめでした、ので改良してみます。&lt;/p></description></item><item><title>tmuxの新しいウインドウを現在のディレクトリで開く</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-28/</link><pubDate>Thu, 28 Jan 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-28/</guid><description>&lt;p>tmuxは、新しいウインドウを開くときセッションを起動したカレントディレクトリで開きます。つまり、&lt;code>~/&lt;/code>でtmuxを起動後、ウィンドウの内部で&lt;code>~/work&lt;/code>に移り、この状態で新しいウィンドウを開くと&lt;code>~/&lt;/code>がカレントディレクトリの状態で開きます。現在の作業の継続なので&lt;code>~/work&lt;/code>で開いてほしいということでネットを検索したら解決方法を見つけました。&lt;/p></description></item><item><title>HackMD CLIをJSON-RPC経由で使う</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-27/</link><pubDate>Wed, 27 Jan 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-27/</guid><description>&lt;p>以前の作った&lt;a href="https://blog.tumf.dev/posts/diary/2021/1/2021-1-22/" target="_blank" rel="noopener noreferrer">shellコマンドをJSON-RPC経由で実行する
&lt;/a>
を利用して&lt;a href="https://hackmd.io" target="_blank" rel="noopener noreferrer">HackMD&lt;/a>
を外部からAPIで操作できるようにしたいと思います。&lt;/p>
&lt;p>HackMDには&lt;a href="https://github.com/hackmdio/hackmd-cli" target="_blank" rel="noopener noreferrer">CLI&lt;/a>
が提供されていますので、以前つくったJSON-RPCのDockerイメージにこのCLIをインストールして利用してみたいと思います。&lt;/p></description></item><item><title>sshconf ver2改</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-26/</link><pubDate>Tue, 26 Jan 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-26/</guid><description>&lt;p>以前書いた記事&lt;a href="https://blog.tumf.dev/posts/diary/2021/1/2021-1-13/" target="_blank" rel="noopener noreferrer">~/.ssh/configを分割して管理する ver2&lt;/a>
のスクリプト&lt;code>sshconf&lt;/code>改良をしましました。以前といってもたった数週間前であり、そもそもその記事自体が改良記事でしたが改良の改良ということでお許しください。&lt;/p></description></item><item><title>Docker: ポート公開・開放でよくあるトラブルと解決法</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-25/</link><pubDate>Mon, 25 Jan 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-25/</guid><description>&lt;p>初めてDockerを扱うエンジニアを見てるとDockerポート周りで悩んでいる人を見かけます。別に難しい事はないのですが確かに紛らわしい事もありますのでまとめました。&lt;/p>
&lt;p>結局ポートの問題とは、&lt;code>公開されない&lt;/code>と意図せず&lt;code>公開されちゃう&lt;/code>に帰着されます。つまりこんな感じ・・・&lt;/p>
&lt;ul>
&lt;li>Dockerfile内でEXPOSEしたのに公開されない&lt;/li>
&lt;li>ufwで閉じたはずなんだけどアクセスできちゃう&lt;/li>
&lt;li>docker-compose でlinkしてないのに&amp;hellip;&lt;/li>
&lt;li>起動時にデータベースにアクセスできない&lt;/li>
&lt;/ul>
&lt;p>思いついた順に簡単にまとめました。&lt;/p></description></item><item><title>traefikでLetsEncryptのワイルドカードSSLサーバ証明書を使う</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-24/</link><pubDate>Sun, 24 Jan 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-24/</guid><description>&lt;p>以前書いた&lt;a href="https://traefik.io/" target="_blank" rel="noopener noreferrer">traefik&lt;/a>
関連記事、&lt;a href="https://blog.tumf.dev/posts/diary/2021/1/2021-1-16/" target="_blank" rel="noopener noreferrer">1つのサーバにたくさんのWebサービスを詰め込む方法&lt;/a>
にて&lt;code>whoami.example.com&lt;/code>のサービスを作成しましたが、とある理由で&lt;code>whoami.example.com&lt;/code>をサブドメインとするホストすべてからアクセスできるようにしたい、つまり&lt;code>a.whoami.example.com&lt;/code>や&lt;code>b.whoami.example.com&lt;/code>などを使いたいときにどうすればよいかを説明します。&lt;/p></description></item><item><title>n8nの紹介とインストール</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-23/</link><pubDate>Sat, 23 Jan 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-23/</guid><description>&lt;p>&lt;a href="https://n8n.io/" target="_blank" rel="noopener noreferrer">n8n&lt;/a>
(Nodemation, n-eight-n:ネイテン)という最近お気に入りのソフトウェアがあります。ブラウザ上でブロックを繋ぐ事でシステムができるという今流行りの&lt;strong>ノーコードプログラミング&lt;/strong>の文脈でよく紹介されるソフトウェアです。一部ではiPaaS(Integration Platform as a Service)とも呼ばれているそうです。&lt;/p>
&lt;p>&lt;img 
 src="https://i.imgur.com/pPSWNyH.png" 
 alt="Bitcoin new block notifer"
 loading="lazy"
 decoding="async"
/>
&lt;/p></description></item><item><title>shellコマンドをJSON-RPC経由で実行する</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-22/</link><pubDate>Fri, 22 Jan 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-22/</guid><description>&lt;p>JSON-RPC経由でシェルコマンドを実行したい事があって、以下のようなRubyスクリプトを書きました。&lt;/p></description></item><item><title>OpenWrtトラベルルータGL-AR750SにSyncthingでファイルを同期する</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-21/</link><pubDate>Thu, 21 Jan 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-21/</guid><description>&lt;p>旅行(出張)には&lt;a href="https://www.gl-inet.com/" target="_blank" rel="noopener noreferrer">GL.iNet&lt;/a>
社製&lt;a href="https://openwrt.org/" target="_blank" rel="noopener noreferrer">OpenWrt&lt;/a>
トラベルルータ &lt;a href="https://amzn.to/3ijOygz" target="_blank" rel="noopener noreferrer">GL-AR750S-Ext&lt;/a>
が便利です。滞在先の有線・無線ネットにこれだけ接続すれば、手持ちのデバイス全てがネットに繋がります。&lt;a href="https://www.wireguard.com/" target="_blank" rel="noopener noreferrer">WireGuardVPN&lt;/a>
 サーバ・クライアントにもなるので、持ち運び用と拠点用で3台使っています。&lt;/p></description></item><item><title>ngrokに飽きたらFRPもね!〜FRP実践編その2 sshトンネルを作る</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-20/</link><pubDate>Wed, 20 Jan 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-20/</guid><description>&lt;p>&lt;a href="https://blog.tumf.dev/posts/diary/2021/1/2021-1-15/" target="_blank" rel="noopener noreferrer">前回、FRPを使ってサーバを外部に晒す方法を説明しました&lt;/a>
。今回は、FRP実践編その２として拠点間のSSHを扱います。&lt;a href="https://github.com/fatedier/frp" target="_blank" rel="noopener noreferrer">FRP&lt;/a>
の主要な使い方はこの２点なので、このシリーズはこれで最終回となります。さて、タイトルのお正月ネタが尽きないうちに記事を書いてしまいましょう。&lt;/p></description></item><item><title>ブログにタグクラウドを追加してみました</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-19/</link><pubDate>Tue, 19 Jan 2021 03:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-19/</guid><description>&lt;p>このブログの右のサイドバーににタグクラウドを追加してみました。
ちゃんと動いているようですね。&lt;/p>
&lt;p>&lt;img 
 src="https://i.imgur.com/OumvSp4.png" 
 alt="TagCloud"
 loading="lazy"
 decoding="async"
/>
&lt;/p></description></item><item><title>Docker環境を一気にセットアップする</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-18/</link><pubDate>Mon, 18 Jan 2021 12:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-18/</guid><description>&lt;p>レンタルサーバを借りて作業環境を整えたらまずやることはDockerのインストールと言う人は多いのではないでしょうか？&lt;/p>
&lt;p>今日は、私が使っているDockerおよびDockerComposeのインストール方法を紹介します。&lt;/p></description></item><item><title>サーバの作業環境を初期設定をするシェルスクリプト</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-17/</link><pubDate>Sun, 17 Jan 2021 12:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-17/</guid><description>&lt;p>新しい作業用サーバを建てたときに作業環境を真っ先に設置するためのスクリプトに&lt;code>movein.sh&lt;/code>と言う便利なのがあります。&lt;/p></description></item><item><title>1つのサーバにたくさんのWebサービスを詰め込む方法</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-16/</link><pubDate>Sat, 16 Jan 2021 12:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-16/</guid><description>&lt;p>個人的な実験用に&lt;a href="https://m.do.co/c/9943432abe16" target="_blank" rel="noopener noreferrer">DigitalOcean&lt;/a>
でサーバを借りています。せっかくなので一台のサーバにいろんなソフトウェアをインストールして有効活用したいので以下のような仕組みを考案しました。&lt;/p></description></item><item><title>FRP実践編: SSHアクセスとWebサービス公開の設定方法</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-15/</link><pubDate>Fri, 15 Jan 2021 12:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-15/</guid><description>&lt;p>&lt;a href="https://blog.tumf.dev/posts/diary/2021/1/2021-1-12/">前回の記事&lt;/a>
の続きで&lt;a href="https://github.com/fatedier/frp" target="_blank" rel="noopener noreferrer">FRP&lt;/a>
やっていきます。&lt;/p>
&lt;blockquote>
&lt;p>&lt;strong>補足&lt;/strong>（2025年12月更新）: FRP v0.52.0以降では設定ファイル形式がINIからTOMLに変更されました。本記事のINI形式の例はv0.51.x以前向けです。新規セットアップの場合は&lt;a href="https://github.com/fatedier/frp#configuration-files" target="_blank" rel="noopener noreferrer">公式ドキュメント&lt;/a>
のTOML形式を参照してください。&lt;/p>&lt;/blockquote></description></item><item><title>RubyでRocksDBつかうためのDockerイメージ</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-14/</link><pubDate>Thu, 14 Jan 2021 12:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-14/</guid><description>&lt;p>&lt;a href="https://rocksdb.org/" target="_blank" rel="noopener noreferrer">RocksDB&lt;/a>
は組み込みKeyValueStore型のデータベースです。Googleの公開している&lt;a href="https://github.com/google/leveldb" target="_blank" rel="noopener noreferrer">LevelDB&lt;/a>
のForkで、Facebookが公開しています。ちょっとした情報収集系のスクリプト動かすのには便利でよく使っているのですが、コンパイルが少し厄介なのでこの機会にDockerfileをちゃんと書くことにしました。&lt;/p></description></item><item><title>SSH設定ファイル（~/.ssh/config）を分割管理する完全ガイド</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-13/</link><pubDate>Wed, 13 Jan 2021 12:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-13/</guid><description>&lt;p>管理するサーバが増えると、&lt;code>~/.ssh/config&lt;/code>がどんどん肥大化して管理しづらくなりませんか？&lt;/p>
&lt;p>この記事では、SSH設定ファイルを&lt;strong>プロジェクトごと・環境ごとに分割&lt;/strong>して管理する方法を、2025年の最新ベストプラクティスとともに解説します。設定を分割することで、Git管理やチーム共有が容易になり、SSHの運用が格段に楽になります。&lt;/p></description></item><item><title>FRP（Fast Reverse Proxy）入門: ngrok代替のセルフホスト型リバースプロキシ</title><link>https://blog.tumf.dev/posts/diary/2021/1/2021-1-12/</link><pubDate>Tue, 12 Jan 2021 12:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/diary/2021/1/2021-1-12/</guid><description>&lt;p>&lt;a href="https://ngrok.com/" target="_blank" rel="noopener noreferrer">ngrok&lt;/a>
の代替になりそうなソフトウェアを探していたらFRPというすごいのを見つけたのでご紹介します。&lt;/p></description></item><item><title>ブログ開設のお知らせ</title><link>https://blog.tumf.dev/posts/greeting/</link><pubDate>Tue, 12 Jan 2021 00:00:00 +0900</pubDate><guid>https://blog.tumf.dev/posts/greeting/</guid><description>&lt;p>&lt;a href="https://blog.tumf.dev" target="_blank" rel="noopener noreferrer">このブログ&lt;/a>
は、個人的な備忘録です。最近物忘れが酷いので技術関連のテキストをおく場所として設置しました。
&lt;a href="https://blog.tumf.dev/tags/Linux/">Linux&lt;/a>
・&lt;a href="https://blog.tumf.dev/tags/Docker">Docker&lt;/a>
・&lt;a href="https://blog.tumf.dev/tags/Blockchain">ブロックチェーン&lt;/a>
・&lt;a href="https://blog.tumf.dev/tags/NoCode">ノーコード&lt;/a>
などの技術メモを置いていく予定です。
いつまで続くかわかりませんが、1日1記事を公開するつもりでのんびりやっていこうと思います。&lt;/p></description></item><item><title/><link>https://blog.tumf.dev/posts/diary/2025/1/2/python-pytest-pdb/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://blog.tumf.dev/posts/diary/2025/1/2/python-pytest-pdb/</guid><description>&lt;h2 id="description-pytest-pdbの使い方を解説失敗したテストでpdbを起動する方法-xとの組み合わせtracexdist利用時の注意点までまとめます">title: &amp;ldquo;pytest &amp;ndash;pdbの使い方: 失敗したテストでpdbを起動して原因を調べる&amp;rdquo;
date: 2025-01-02T09:00:00+09:00
draft: false
toc: false
categories: [&amp;ldquo;日記&amp;rdquo;]
tags: [&amp;ldquo;python&amp;rdquo;, &amp;ldquo;pytest&amp;rdquo;]
author: &amp;ldquo;tumf&amp;rdquo;
coverImage: &amp;ldquo;/images/python-pytest-pdb/cover-a.png&amp;rdquo;
description: &amp;ldquo;pytest &amp;ndash;pdbの使い方を解説。失敗したテストでpdbを起動する方法、-xとの組み合わせ、&amp;ndash;trace、xdist利用時の注意点までまとめます。&amp;rdquo;&lt;/h2>
&lt;p>&lt;a href="https://blog.tumf.dev/tags/pytest/">pytest&lt;/a>
 で「失敗したテストのその場」に入りたいときは、まず &lt;code>pytest --pdb&lt;/code> を使います。
テストが落ちた瞬間に &lt;code>pdb&lt;/code> が開くので、変数の中身や呼び出し元をその場で確認できます。&lt;/p>
&lt;p>&lt;code>print&lt;/code> を足して再実行するより早く原因に辿り着けることが多いです。
この記事では、&lt;a href="https://docs.pytest.org/en/stable/how-to/failures.html" target="_blank" rel="noopener noreferrer">pytest公式ドキュメント&lt;/a>
 をベースに、&lt;code>--pdb&lt;/code> の基本、&lt;code>-x&lt;/code> や &lt;code>--trace&lt;/code> との違い、&lt;code>pytest-xdist&lt;/code> 利用時の注意点まで整理します。&lt;/p></description></item></channel></rss>