AI

jedipunkz🚀 です。 最初に、これから書く仕組みの完成イメージとして、実際に scrape 処理が走っている動画を貼っておきます。docker compose up scheduler で Go 製スクレイパーが PhilArchive / PhilPapers / arXiv を巡回し、inbox/ 配下に Scrape 結果が次々と書き出されていく様子です。 個人で哲学者・著作ごとのノートを管理しているのですが Notebook LM や Claude Cowork を使い色々と試してきたものの下記の点を課題として持っていました。 新しい情報源の取得の自動化 モバイルアプリでの記事の整理 そこで、Go 製スクレイパーを Docker Compose で定期実行し、PhilArchive / PhilPapers / arXiv といった情報源から関心キーワードに沿った論文を自動収集して inbox/ に蓄積するパイプラインを作りました。蓄積された素材は Codex / Claude Code が読み、既存ノートと照合しながら 研究動向/ ディレクトリに日本語のまとめノートとして統合します。 レポジトリはこちらです: https://github.com/jedipunkz/philosophy 全体アーキテクチャ +-----------------+ | scrape.yaml | +--------+--------+ v +--------------------------------------------------+ docker compose | +------------------+ +------------------+ | | | scraper (Go) | | scheduler (Go) | | | +---------+--------+ +---------+--------+ | | | | | | +-----------+-----------+ | | | | | fetch via HTTP / arXiv API | | | | | +--------------------v-------------------+ | | | PhilArchive / PhilPapers / arXiv | | | +--------------------+-------------------+ | +-------------------------|------------------------+ v +----------------------------+ | inbox/*.md | Obsidian Vault +-------------+--------------+ | | git commit v +----------------------------+ | GitHub (philosophy repo) | +-------------+--------------+ | | pulled from other devices v +----------------------------+ | Codex / Claude Code | reads inbox + existing notes +-------------+--------------+ | v +----------------------------+ | research-trends/*.md | curated Japanese notes +----------------------------+ ポイントは 3 つです。 ...

こんにちは。@jedipunkz です。 2026年6月現時点において、SRE の領域で AI はどう活用されているのか、世の中の SRE はどのように AI に向き合っているのか気になり調査を行いました。普段自分は具体の技術に興味がある人間なのであまりこういう抽象的な話は好まないのですが、AI の進化はここ数ヶ月でも激しく推進しているので SRE の活動にも変化が生じているだろうと気になり調査した次第です（本記事は 5 月に書いたものを 6 月時点の動向で更新しています）。 ここ数ヶ月でひとつ大きかったのは、AI SRE がひとつの独立した市場カテゴリとして認知されたことです。Gartner は 2026 年初頭に初の Market Guide for AI Site Reliability Engineering Tooling を公開し、2029 年までに 85% の企業が AI SRE ツールを運用に使うようになる（2025 年時点では 5% 未満）と予測しています (Komodor)。Komodor、CAST AI、Firefly などが Representative Vendor として挙げられ、加えて Microsoft は Azure SRE Agent を 2026 年 3 月 10 日に GA しています。実験段階のツールが乱立する状態から、評価軸や代表的プレイヤーが定まりつつある段階に移ったと言えそうです。 AI SRE の分類 調査の結果、AI を SRE 領域に適用するアプローチは概ね以下の施策に分類できました。 1. AI によるインシデントトリアージと原因分析 最も広く普及しているアプローチが AI によるインシデント対応です。AI はログ、メトリクス、トレース、変更履歴、過去インシデントという情報を横断的に相関させ、「何が起きているか」だけでなく「なぜ起きたか」という原因候補を提示します。 ...

jedipunkz です。 複数の AI コーディングエージェントを、それぞれ独立した git worktree で並列に走らせ、その状態を1つのターミナルからまとめて見る。そのための CLI ツール agx を Go で作りました。この記事では作った動機と、使い方、内部の設計について書きます。 リポジトリはこちらです: https://github.com/jedipunkz/agx なぜ作ったか Claude Code を日常的に使う中で、複数のエージェントを同時に動かしたいというシーンが増えてきました。例えば複数の独立したタスクを並列で走らせたいとき、それぞれのエージェントが今どんな状態にあるかをターミナル1つで把握したいと思っていました。 以前Zellij を使って Claude Code のマルチエージェント並列・直列実行環境を作った という記事を書いたのですが、これは1つのレポジトリに対して複数の機能開発・リファクタ・その他修正を並列でそれぞれ別の Claude Code で行い最終的にそれぞれの git worktree 上の差分をマージする統合管理 Claude Code を実現するものでした。これは Claude Code 純正の機能 Sub Agents とは異なり複数の Claude Code をオーケストレーションするモノとして利用していたのですが、対象が1つのレポジトリに限定されること、また最終的にそれぞれの差分をマージするのであれば Sub Agents で事足りる事も多くなってきていました。 それに対して最近の要件としては下記のように変化してきました。 複数のレポジトリの修正を行いたい それぞれのエージェントのオーケストレーションよりも、それぞれの可視化と管理をしたい つまり必要なのはオーケストレーターではなく、並列に動いている多数のエージェントを一望できるダッシュボードでした。そこで作ったのが agx です。 agx とは agx は「1つのターミナルから複数の AI コーディングエージェントを起動・監視する」ための CLI ツールです。できることは大きく3つです。 隔離された環境でエージェントを起動する — git リポジトリ内で実行すると専用の git worktree を作り、その中でエージェントを動かします。互いの変更もメインの作業ツリーも汚しません 全エージェントの状態を一望する — TUI ダッシュボードで、どれが処理中で、どれが入力待ちで、どれが終わったのかをリアルタイムに表示します 別のターミナルから扱う — 実行中のエージェントのログ追従・差分表示・終了待ち・入力送信を、起動した端末とは別の場所から行えます 対応しているエージェントは Claude Code / Codex CLI / Gemini CLI / OpenCode の4つで、起動時に -a で選びます。 ...

jedipunkz🚀 です。 Claude Code を日常的に使う中で、大きなタスクを複数の独立したサブタスクに分けて並列処理させたいというニーズが出てきました。例えばコードのリファクタリングとテスト追加を同時に進めたり、複数ファイルへの独立した修正を並行して行ったりといったケースです。 2026年2月に Claude Code Agent Teams という機能が出てきたのですが、あくまでも1つのタスクの中で複数のサブエージェントを稼働させるものだったので自分としては期待していたものと若干異なりました。やりたいのは親 Claude Code のプロンプトから指示を出して複数のタスクを行ってくれる子 Claude Code のオーケストレーションでした。 そこで、Zellij の Pane 管理と git worktree を組み合わせて、親 Claude Code が複数の子エージェントを Zellij Pane として起動しタスクを並列・直列実行させる SKILL「zellij-swarm」を作りました。この記事ではその仕組みと使い方を紹介します。 SKILL は以下に置いていました (現在は dotfiles から削除済みのため、削除前のコミットを指しています): https://github.com/jedipunkz/dotfiles/tree/a3ed0fbb08f96806182a58950c4e395ae7cd31f0/.claude/skills/zellij-swarm 概要 親 Claude Code に対して「swarm で〜して」と自然言語で指示を出すと、タスクを複数のサブタスクに分解し、それぞれを別々の Zellij Pane で動く子 Claude Code エージェントとして起動するオーケストレーションの仕組みです。 各エージェントは独立した git worktree 上で作業し、完了後に親エージェントが各ブランチをマージして Git worktree の後片付けまで行います。 タスク間に依存関係がある場合は フェーズ に分割して対応します。同一フェーズ内のエージェントは並列実行、フェーズ間は直列実行です。 実行フローの構造 パターン 1: 並列のみ (依存関係なし) タスク A と B が互いに独立している場合、1 フェーズで並列実行して終了します。 [agent-a] ─┐ ├─ run-phase.sh ── merge [agent-b] ─┘ |-------| phase 1 パターン 2: 並列 → 直列 (フェーズ制御) タスク C がタスク A・B の結果に依存する場合、2 フェーズに分けます。Phase 1 完了・マージ後に Phase 2 が起動するため、C は A・B の成果を引き継いだ状態で作業できます。 ...

jedipunkz🚀 です。 最近、AI コーディングアシスタントとして使っていた Claude Code から OpenCode に移行しました。この記事では OpenCode の優れた機能と、なぜ移行を決めたのかの決めてを紹介します。 注記 (2025-12-28) OpenCode プロジェクトは、2024年7月に開発元の Charm 社による買収と運営方針を巡って、コントリビューター間で論争が発生しました。その後、Charm 版は Crush としてリブランドされ、現在の OpenCode は SST 組織によって https://github.com/sst/opencode で開発が継続されています。両プロジェクトは現在も別々のツールとして存在しており、この記事では SST 版の OpenCode について紹介しています。 OpenCode とは OpenCode は、ターミナルベースのオープンソース AI コーディングエージェントです。75以上の LLM プロバイダーをサポートし、高度にカスタマイズ可能なインターフェースを提供します。 公式サイト: https://opencode.ai/ 公式ドキュメント: https://opencode.ai/docs GitHub: https://github.com/opencode-ai/opencode Claude Code から移行した理由 1. 日本語入力 Claude Code では、日本語入力の変換中に文字が横にずれる現象が頻繁に発生し、非常にストレスでした。 OpenCode では、この問題が発生せず日本語入力が自然に行えます。地味ですが一番自分にとって大きいメリットだったかもしれません。 2. 柔軟なキーバインド設定 OpenCode の最大の魅力は、キーバインドを自由にカスタマイズできる点です。 日本語入力 Claude Code では、日本語入力の変換中に文字が横にずれる現象が頻繁に発生し、非常にストレスでした。 OpenCode では、この問題が発生せず、日本語入力が自然に行えます。TUI（Terminal User Interface）の実装が優れており、IME との相性も良好です。 Emacs 風のキーバインドをサポート Emacs 風のキーバインドが設定出来る点は自分にとっては大きかったです。設定せずとも自然に Emacs 風にバインドされているキーもあります。 Ctrl-a: 行頭に移動 Ctrl-e: 行末に移動 Ctrl-h: 一文字削除 Ctrl-k: カーソル位置から行末まで削除 Ctrl-f, Ctrl-b: 前後に移動 "keybinds": { "input_backspace": "backspace,shift+backspace,ctrl+h", "input_delete_to_line_end": "ctrl+k" }, Enter と Ctrl-Enter を使い分け可能 特に便利なのが、改行とメッセージ送信を分離できる点です： ...

自分は Platform Enabler/SRE として従事しています。また AI 関連のアップデートは2025年に入っても属に更新されています。2025年初頭においては自分たちの分野でも AI 関連の利用に関して様々な模索がある状況だと思われますが、Ahthoropic 社が提唱した MCP (Model Context Protocol) がもたらすインパクトはアプリケーションに限定されずインフラ領域のソフトウェアにも大きなメリットをもたらすと思って観測しています。 この記事では、MCP の概要とどう実装するのかの学習、またどう我々のような Platform Enabler/SRE にとっての活用例があるかを考察していきたいと思っています。 MCP の概要 MCP (Model Context Protocol) は、AI モデルと外部システム間のやり取りを効率化するプロトコルで JSON-RPC でやりとりします。ユーザーの自然言語入力を基に、AI アシスタントが MCP サーバーを通じてファイル操作やデータ処理を実行します。 最近 OpenAI 社もこの Anthropic 社の MCP をサポートするというニュースが流れ、途端に注目を集める状況になってきました。 処理の流れ ここはあくまでの一例です。Assistant の実装でいかようにも出来ると思います。 +-------------+ +-----------+ +------------+ +--------+ | User Prompt | <-----> | Assistant | ---> | MCP Server | | AI API | +-------------+ (1),(5) +-----------+ (3) +------------+ +--------+ | ^ | (2),(4) | +----------------------------------+ (1) ユーザからの入力を Assistant が受け取る (2) Assistant はユーザからの自然言語を LLM に問い合わせ。その際に LLM に外部機能を定義 (JSON-RPC(MCP サーバが受け取る)) (3) Aasistant は MCP Server に JSON-RPC でクエリ送信しレスポンスを得る (4) Assistant は MCP Server から得たレスポンスを再び LLM に送信し自然言語としてユーザに返す内容を生成してもらう (5) Assistant はユーザに自然言語で結果を応答する 前提 MCP 学習を目的にしているので、ここでは話を簡潔にするため Linux Filesystem を操作する MCP Server を書き、理解していきます。 ...