GitHub

開発者にとって、GitHubは事実上の「最強のナレッジベース」になりつつあります。Issue・PR・Wiki・Markdown ドキュメント — 仕事に必要な情報のほとんどがリポジトリの中で完結しており、コードの近くにドキュメントを置く「Docs as Code」のスタイルは、エンジニアリングとして極めて洗練されています。 それでも 2026 年に入ってから、「AI Agent + Obsidian」の組み合わせが開発者コミュニティでホットになり続けています。GitHub で完結しているなら無理に Obsidian を入れる必要はないはずなのに、なぜこれほど話題になるのか。本記事ではその違いを、特に AI Agent に渡せる「文脈の質」 という観点から整理します。 結論を先に書くと、すべてが構造化された「プロジェクト」単位で完結していて、現状の運用にストレスがないのであれば、無理に Obsidian を導入する必要はありません。ただし、「プロジェクトを跨いだ伏線回収」を AI にやらせたい瞬間が来ると、思想の違いが効いてきます。 GitHub方式とObsidian方式の決定的な違い 最大の違いは、情報の「繋がり方」の思想です。 比較軸 GitHub方式（プロジェクト管理型） Obsidian方式（ネットワーク型） 情報の構造 ディレクトリ構造（階層型・縦割り） グラフ構造（網の目型・横断的） 主な単位 リポジトリ / Issue / PR / Wiki ノート（アイディア、ファクト、ログなど） AIとの相性 コンテキストがプロジェクト内に閉じる プロジェクト間を跨いだ「点と点の結合」が得意 向いている情報 目的・ゴール・成果物が明確なもの 抽象的なアイディア、長期的な知見、個人の備忘録 検索の単位 リポジトリ単位の全文検索 Vault 全体のリンク・タグ・全文検索 GitHub は「プロジェクトという箱」に閉じることで一貫性と版管理を担保します。Obsidian は「ノート」というアトミックな単位を Vault 全体にフラットに置き、[[リンク]] で網の目を作ることで横断性を担保します。どちらが優れているという話ではなく、扱う情報の性質によって適切な箱が違うだけです。 「プロジェクトの壁」を越える横断性 GitHub はリポジトリごとに境界線がはっきり分かれています。これは「コードと文脈をセットで版管理する」目的にはとても合っていますが、知識の再利用にはコストがかかります。 GitHub の場合: プロジェクト A で得た「Next.js の認証に関する知見」は、リポジトリ A の docs/ か Wiki か Issue 内コメントに残ります。プロジェクト B を始めたときにそれを再利用するには、「どこに書いたか」を思い出して検索しに行く必要があります。複数リポジトリを横串で検索したい場合は gh search code などに頼ることになります。 Obsidian の場合: 「Next.js の認証」という独立したノートを作っておき、プロジェクト A からも B からもリンクを貼ります。情報がプロジェクトに属するのではなく、知見そのものが独立して進化していく点が決定的に違います。 つまり、GitHub は「プロジェクトに紐づく情報」を蓄積するのに最適で、Obsidian は「プロジェクトから独立した知見」を蓄積するのに最適だ、と整理できます。 ...

概要 Graphite は GitHub 上の PR ワークフローを拡張する開発者プラットフォーム。2025年3月に Anthropic から $52M の Series B を調達。元 Airbnb・Meta エンジニア出身チームが、Meta 内部ツール（Phabricator/Sapling）のスタック開発体験を GitHub に持ち込んだ。AI が大量に PR を量産する「AI ファースト開発」環境での詰まりを解消する。 3本柱 1. スタックドPR 大きな変更を依存関係のある小さな PR の連鎖に分割する。DB スキーマ→API→認証ミドルウェアのような依存チェーンを独立した PR として管理し、レビュアーの認知負荷を下げる。 1 2 3 gt stack # 現在のスタック状態を確認 gt submit # スタック全体を一括 PR 作成 gt sync # main の変更を全 PR にリベース 2. マージキュー（スタック対応） スタックの依存関係を理解した上で main へのマージを直列化。CI が通ったものから順番にマージされるため、コンフリクトなしに高頻度デプロイが可能になる。 3. Graphite Agent（旧 Diamond） AI によるコードレビューと対話的修正。差分を理解した上でコメントし、Chat で修正まで完結できる。 ...

CreaoAI が25名で6週間のリリースサイクルを1日に短縮した事例では、PR 管理ツールとして Graphite が採用されていた。1日8回デプロイ・AI が大量に PR を量産する運用で、素の GitHub PR フローは何が詰まり、Graphite は何を解決するのか。本記事では Graphite の3本柱（スタックドPR・マージキュー・AIレビュー）を、CLI コマンドと具体的な運用シナリオで解説する。 Graphite とは Graphite は GitHub 上の PR ワークフローを拡張する開発者プラットフォーム。2025年3月に Anthropic から $52M の Series B を調達し、同時に AI コードレビュー「Diamond」をローンチした（現在は Graphite Agent に名称統合）。元 Airbnb・Meta のエンジニア出身チームが、Meta 内部で使われていた Phabricator / Sapling 的なスタック開発体験を GitHub に持ち込んだのが出発点だ。 主要機能は3つに整理できる。 スタックドPR — 大きな変更を依存関係のある小さな PR の連鎖に分割する マージキュー — スタックを理解した状態で main にマージを直列化する（stack-aware） Graphite Agent（旧 Diamond）+ Chat — AI によるコードレビューと対話的修正 スタックドPR：大きな差分を「小さなレビュー単位の連鎖」に分解する 何が問題だったのか AI エージェントや生産性の高い開発者は、1つのフィーチャーを実装する過程でしばしば以下のような複数階層の変更を生む。 DBスキーマの追加 それを使う API エンドポイント 認証ミドルウェアの更新 フロントエンドの呼び出し 従来の GitHub PR モデルだと選択肢は2つしかない。 ...

概要 Kevin Gu 氏（Third Layer CTO）が開発した Python 製 OSS ライブラリ。メタエージェントとタスクエージェントの二重構造で、エージェントのハーネス（プロンプト・ツール・オーケストレーション）を自律的に最適化する。24時間の自律最適化で SpreadsheetBench・TerminalBench 世界1位を達成。 基本情報 GitHub: kevinrgu/autoagent ライセンス: MIT 言語: Python 依存: Docker, Python 3.10+, uv ベンチマーク ベンチマーク スコア 順位 SpreadsheetBench 96.5% 1位 TerminalBench（GPT-5スコア） 55.1% 1位 プロジェクト構成 agent.py -- ハーネス本体（メタエージェントの編集対象） program.md -- メタエージェントへの方針指示（人間が編集） tasks/ -- 評価タスク（Harbor フォーマット） 人間は program.md にゴールを書き、agent.py の改善はメタエージェントに任せる。 関連ページ 自己改善エージェント — AutoAgent が実装するパターン Claude Code — メタエージェントの実行環境として利用可能 ソース記事 AutoAgent — AIがAIを育てる自己改善エージェントOSSライブラリ — 2026-04-05

AIエージェントの性能を左右する「ハーネス」を、AI自身が自律的に改善するOSSライブラリ AutoAgent が公開されました。ハーネスとは、システムプロンプト・ツール・オーケストレーションから成るエージェントの構成一式のことです。24時間の自律最適化だけで、SpreadsheetBench と TerminalBench の2つのベンチマークで世界1位を達成しています。 AutoAgent とは AutoAgent は Kevin Gu 氏（Third Layer CTO）が開発したPython製OSSライブラリで、「AIがAIを育てる」仕組みを提供します。 従来、AIエージェントを実用レベルにするには、システムプロンプトの調整、ツールの追加、実行フローの設計といった「ハーネス設計」が不可欠でした。この作業は専門知識を要し、1つのハーネスに何日もかかることがあります。AutoAgent はこのハーネス設計をAI自身に任せることで、人間の手動チューニングを超える精度を実現しました。 GitHub: kevinrgu/autoagent ライセンス: MIT 言語: Python ベンチマーク結果 ベンチマーク スコア 順位 SpreadsheetBench 96.5% 1位 TerminalBench（GPT-5スコア） 55.1% 1位 他のエントリーはすべて人間が手動チューニングしたものです。AutoAgentだけが自律的にこのスコアに到達しました。 仕組み: メタエージェントとタスクエージェント AutoAgent は2つのAIの役割分担で動作します。 メタエージェント（コーチ役） ハーネスを改良することが仕事。タスクエージェントの失敗トレースを読み、プロンプト・ツール・オーケストレーションを書き換えます。 タスクエージェント（選手役） 実際のタスクをこなすことが仕事。メタエージェントが設計したハーネスに従って作業を実行します。 最適化ループ 人間がやることは、AutoAgent の設定ファイル program.md にゴール（成功の定義）を書くだけです。あとはAIが24時間、以下のループを回します: メタエージェントがハーネスを書き換える タスクエージェントがタスクを実行する スコアを測定する 失敗トレースを分析し「なぜ失敗したか」を特定する 改善なら採用、悪化なら元に戻す 1に戻る これを数千の並列サンドボックス（隔離された実行環境）で同時実行します。 なぜAIのほうが上手く改善できるのか — 「モデル共感」 人間はどうしても自分の感覚でAIを設計してしまいます。しかし、AIは人間とは異なる思考回路で動いています。 同じモデル同士（例: Claude × Claude）でペアリングすると、コーチ（メタエージェント）は選手（タスクエージェント）の「失敗パターン」を自分ごととして理解できます。同じ重みを共有しているため、内側のモデルがどう推論するかを正確に把握できるのです。 AutoAgent の開発チームはこれを 「モデル共感（model empathy）」 と呼んでいます。実際に、Claude メタエージェント + Claude タスクエージェントの組み合わせは、Claude メタエージェント + GPT タスクエージェントの組み合わせよりも高い性能を示しました。 ...

以前の記事で紹介した AI 予測エンジン「MiroFish」が、公開から約3週間で GitHub Star 4.7万超にまで急成長しています。本記事では、その後の動向とコミュニティの広がりを追います。 3週間での急成長 3月10日時点で約11,000だった Star 数は、3月末時点で 47,000以上 に到達しました。約3週間で4倍以上の成長です。 GitHub Trending で世界1位を獲得した直後の注目度に加え、盛大グループ創業者・陳天橋氏からの3,000万元（約6億円）の即決投資が報じられたことで、AI エージェント分野への関心の高さを示すプロジェクトとして広く認知されました。 コミュニティの広がり MiroFish のオープンソース公開後、コミュニティによる派生プロジェクトが活発に展開されています。 オフライン版フォーク MiroFish-Offline は、Neo4j と Ollama を使ったローカル完結型のフォークです。クラウド API への依存を排除し、プライベートな環境でマルチエージェントシミュレーションを実行できます。企業内のデータを外部に出せないケースなどでの活用が想定されます。 デモサイト 公式デモサイトが公開されており、ブラウザ上で MiroFish の予測プロセスを体験できます。 多言語対応フォーク 英語版 README の整備や、コミュニティによる英語フォークも複数登場し、中国語圏以外への普及が進んでいます。 群体知能アプローチへの注目 MiroFish が採用する群体知能（Swarm Intelligence）アプローチは、従来の AI 予測と異なる特徴を持っています。 従来の予測モデルは統計的パターンや単一モデルの推論に依存しています。一方、MiroFish は数千のエージェントによる社会的シミュレーションを通じて予測を行います。エージェント同士が議論し、説得し、立場を変えるプロセスを経ることで、集団行動や社会的伝播といった創発的パターンを予測に反映できます。 このアプローチは、特に世論形成や市場心理のような「人間の集団行動」が結果を左右する領域で有効性が期待されています。 今後の注目点 MiroFish の急成長は印象的ですが、今後の展開にはいくつかの注目点があります。 予測精度の検証: 実際のイベントに対する予測精度がどの程度か、体系的な評価はまだ少ない スケーラビリティ: OASIS エンジンは100万エージェント対応を謳うが、実運用での性能と品質のバランス LLM コスト: 数千エージェントの同時推論に必要な API コストの最適化 ユースケースの深化: 汎用的な「万物を予測」から、特定領域での実用性の実証 まとめ MiroFish は、公開からわずか3週間で GitHub Star 4.7万超という驚異的な成長を遂げました。オフライン版フォークやデモサイトの登場など、コミュニティの展開も活発です。 群体知能によるマルチエージェント予測というコンセプトは多くの開発者の関心を集めていますが、実用面での検証はこれからです。今後の予測精度の実証やユースケースの深化に注目していきたいプロジェクトです。 参考リンク MiroFish GitHub リポジトリ MiroFish-Offline (ローカル版フォーク) MiroFish: The AI Swarm Engine That Simulates the Future 前回の記事: MiroFish — 20歳の学生が10日間の Vibe Coding で作った AI 未来予測エンジン

Claude Codeのベストプラクティスが毎日TLに流れてくる。追いかけるのに疲れた人向けに、1つのリポジトリだけをフォローして運用する方法を紹介する。 ベストプラクティス疲れという問題 Claude Codeの普及に伴い、SNS上には日々さまざまなベストプラクティスやTipsが投稿されている。しかし、情報が断片的で、どれを採用すべきか判断するだけでも消耗する。 結論として、ベストプラクティスを追うことに時間を費やすより、具体的な仕組みの実装に時間を割いた方が生産的だ。 claude-code-best-practiceリポジトリとは shanraisshan/claude-code-best-practice は、Claude Codeの設計や運用に関するベストプラクティスを体系的にまとめたリポジトリだ。 GitHub Star数: 約24,800（2026年3月時点） 海外コミュニティで広く参照されている 設計思想から具体的な設定まで、日々更新されている 日本のSNSでバズるClaude Code Tipsも、元ネタはこのリポジトリ周辺であることが多い 導入手順 やることは2ステップだけ。 Step 1: リポジトリをクローン 1 git clone https://github.com/shanraisshan/claude-code-best-practice.git Step 2: Claude Codeにプロジェクト固有のベストプラクティスを提案させる 自分のプロジェクトディレクトリでClaude Codeを起動し、以下のように依頼する: このリポジトリ（claude-code-best-practice）を参考に、 うちのプロジェクトに合ったベストプラクティスを提案して Claude Codeがプロジェクトの構成を読み取り、適切なCLAUDE.mdの設定やSkills、エージェント構成を提案してくれる。 startup hookで常に最新化する クローンしたリポジトリは時間とともに古くなる。Claude Codeの SessionStart hook（セッション開始時に自動実行される仕組み）に git pull を設定しておけば、起動のたびに自動で最新化される。 Claude Codeのユーザー設定ファイル（~/.claude/settings.json）に以下を追加する: 1 2 3 4 5 6 7 8 9 10 11 { "hooks": { "SessionStart": [ { "type": "command", "command": "cd /path/to/claude-code-best-practice && git pull --quiet", "timeout": 10000 } ] } } /path/to/ の部分は、Step 1でクローンした実際のパスに置き換えること。 ...

opencli-rs は、55以上の主要サイトに対応したRust製のCLIツールです。サイトごとにAPIやスクレイピング方法が異なる煩雑さを解消し、1つのコマンドで各プラットフォームの情報を取得できます。 opencli-rs とは opencli-rs は、元々TypeScriptで実装されていた OpenCLI をRustで完全に書き直したツールです。X (Twitter)、YouTube、Reddit、Hacker News、Bilibili、Zhihu、Xiaohongshu（小紅書）など多数のプラットフォームに対応しています。Chromeのログインセッションを再利用するため、APIキーなしでデータを取得できます。 出力形式はテーブル、JSON、YAML、CSV、Markdownに対応しており、用途に応じて使い分けが可能です。また、Electronベースのデスクトップアプリをコマンドラインから制御する機能も備えており、GUIアプリの操作をスクリプト化できます。 主な特徴 処理速度が最大12倍に向上 — TypeScript版と比較して大幅な高速化（例: Bilibili Hot の取得が20.1秒から1.66秒に） メモリ使用量を10分の1に削減 — 95-99MBから9-15MBへ シングルバイナリで動作 — わずか4.7MB、追加のランタイム不要でどの環境にも導入可能 インストール インストールスクリプトが用意されており、システムとアーキテクチャを自動検出してバイナリをダウンロードします。 1 curl -fsSL https://raw.githubusercontent.com/nashsu/opencli-rs/main/scripts/install.sh | sh Rustの開発環境がある場合はソースからビルドすることもできます。 1 2 3 git clone https://github.com/nashsu/opencli-rs.git cd opencli-rs cargo build --release AIエージェントとの連携 opencli-rs はAIエージェントとの連携を前提に設計されています。Claude Code や Cursor などに組み込むことで、「Hacker Newsのトップ記事を取得して要約する」「競合のX投稿を定期的にチェックする」といったWeb情報収集の自動化が可能です。 AIエージェント向けのスキルパッケージ opencli-rs-skill も提供されています。 1 npx skills add https://github.com/nashsu/opencli-rs-skill これにより、AIエージェントが AGENT.md や .cursorrules の設定を通じて利用可能なツールを自動的に検出し、自然言語でWebスクレイピングを実行できるようになります。 ...

オープンソースの自律エージェント Dexter が注目を集めている。X では「Claude Code の金融版」と紹介され話題になった。約200行のコードで、銘柄スクリーニングから財務分析、投資根拠のレポート作成までを自動で行うツールだ。 Dexter とは Dexter は、virattt 氏が開発したオープンソースの自律型金融リサーチエージェント。2026年3月時点で GitHub スター数は 18,000 を超える。複雑な金融の質問を受けて、自分でリサーチ計画を立て、データを収集し、結果を検証してレポートにまとめる。 主な機能: 割安な銘柄の自動スクリーニング 財務データの詳細分析 投資根拠のレポート化 作業内容の自己検証（セルフバリデーション） アーキテクチャ: 4つのエージェント構成 Dexter は ReAct（Reasoning + Acting）パターンに基づくマルチエージェントアーキテクチャで構成されている。ReAct とは、LLM が「考える（Reasoning）」と「行動する（Acting）」を交互に繰り返すことで、複雑なタスクを段階的に解決するパターンだ。 エージェント 役割 Planning 金融クエリを分析し、リサーチ計画をステップに分解 Action 計画に基づいてツールを呼び出し、リアルタイムデータを取得 Validation 各ステップの完了を検証し、データの十分性をチェック Answer 収集した情報を統合してレポートを生成 この Validation エージェントが Dexter の特徴的な部分だ。金融分野では精度が重要なため、自分自身の出力を検証するレイヤーを設けている。ループ検出やステップ数制限などの安全機構も備えている。 技術スタック ランタイム: Bun（高速な JavaScript ランタイム） 言語: TypeScript UI: React + Ink（React コンポーネントでターミナル UI を構築するライブラリ） LLM オーケストレーション: LangChain.js LLM プロバイダ: OpenAI、Anthropic、Google、ローカル Ollama に対応 データソース: Financial Datasets API（リアルタイム市場データ） 始め方 リポジトリをクローンして依存関係をインストールする。 ...

OpenAI初期メンバーであるAndrej Karpathyが、autoresearchというオープンソースツールを公開しました。わずか630行のPythonスクリプトで、寝ている間にAIエージェントが約100の機械学習実験を自律的に実行してくれるというものです。 Karpathy「12月からコードを1行も書いていない」 Karpathyは「12月から自分でコードを1行も書いていない」と告白しています。代わりに公開したのがこのautoresearchで、プログラマーの仕事が「コードを書く」から「設計する」へとシフトしていることを象徴しています。 autoresearchの仕組み autoresearchはシンプルな仕組みで動作します: AIエージェントにトレーニングスクリプトと固定の計算バジェット（通常5分間のGPU時間）を渡す エージェントが自分のソースコードを読み、改善の仮説を立てる コードを修正し、実験を実行する 結果が改善されたかを評価し、改善なら保持・悪化なら破棄する このサイクルを繰り返す トレーニングは常に5分間で実行されるため、1時間あたり約12実験、一晩で約100実験が自動的に回ります。 実績と反響 Shopify CEO Tobias Lütke: 一晩で37実験を実行し、性能19%向上を達成 Karpathy自身: 700以上の実験を2日間で実行（Fortune誌報道） GitHub: 公開1週間で数万スターを獲得（現在54,000以上） 技術的特徴 シングルGPU対応: 高価なクラスタは不要 630行のスクリプト: コードベースが小さく、理解・カスタマイズが容易 MITライセンス: 誰でも自由に利用可能 Python製: train.py を中心としたシンプルな構成 リポジトリ GitHub: karpathy/autoresearch 「書く」から「設計する」への転換 autoresearchが示唆しているのは、世界最高峰のプログラマーの仕事が「AIにコードを書かせる」段階をすでに超え、AIエージェントに実験を設計・実行させるフェーズに入っているということです。Karpathyは将来的に、エージェント群が協調して小さなモデルをチューニングし、有望なアイデアを段階的にスケールアップさせる「研究コミュニティのエミュレーション」を構想しています。