Claude Code の「Dynamic Workflows」を冷静に検証 — Opus 4.8 + /ultracode で本当に変わること・誇張されていること

はじめに X(旧 Twitter)でこんな投稿が流れてきました。 【衝撃】Claude Code でとんでもないモードが解禁👀 Opus 4.8 + /ultracode で有効になる新機能「Dynamic Workflows」! ・タスク難易度を自動検知 ・オーケストレーション用スクリプトを生成 ・複数エージェントに役割分担 ・検証フローまで自動構築 ・エージェントスウォームで並列実行 つまり開発フローの全工程を Claude が自走。 「人間はゴールを投げるだけ、Claude Code が PM + 開発チームを自動編成して並列実行する」——確かにインパクトのある話です。 ただ、こういうバイラル投稿は機能を過度に一般化しがちです。本記事では、/ultracode と Dynamic Workflows の実体を公式ドキュメントと実機の挙動から整理します。そのうえで「本当に変わること」と「誇張されていること」を切り分けます。結論から言うと、機能はほぼすべて実在しますが、“完全自動” ではありません。 Dynamic Workflows とは何か Dynamic Workflows は、Claude Code が複数のサブエージェントを JavaScript スクリプトで決定論的にオーケストレーションする機能です。現在は research preview(研究プレビュー)として提供されています。 ポイントは「決定論的」という部分です。通常のエージェントはモデルが自分の判断で次の手を決めますが、Workflow ではループ・分岐・ファンアウト(並列展開)といった制御フローをスクリプトで明示的に記述します。「何を並列にやるか」「何を検証するか」「何を統合するか」を人間(あるいは Claude)がコードとして固定できるわけです。 スクリプトは export const meta = {...} で始まり、本体で以下のような構成要素を使います。 phase(title) — フェーズ(工程)を区切る agent(prompt, opts) — サブエージェントを 1 体起動する parallel(thunks) — 複数タスクを並列実行する(全完了を待つバリア) pipeline(items, stage1, stage2, ...) — 各アイテムを複数ステージに流す(ステージ間でバリアなし) これらは実際の Workflow ツールが提供する API です。最小の例を見てみましょう。 ...

2026年5月29日 · 2 分

AIエージェント時代に再注目される FDE(Forward Deployed Engineer)— 前線配備型エンジニアという働き方

AIエージェントが業務システムに本格導入される時代に入り、「FDE(Forward Deployed Engineer)」というエンジニア職種が改めて注目を集めています。AIエージェントを現場の業務フローに組み込み、「成果が出るまで」を一気通貫で推進する役割です。なぜ今このモデルが再評価されているのか、その役割と重要性を整理します。 FDE(Forward Deployed Engineer)とは FDEは「フォワード・デプロイド・エンジニア(前線配備型エンジニア)」の略です。Palantir が2011年に考案したモデルで、エンジニアを顧客環境に直接埋め込む形で生まれました。AIエージェントの実用化が加速する中で、この働き方が改めて脚光を浴びています。 役割の核心 FDEは開発拠点に留まらず、顧客や社内の業務現場に深く入り込みます。AIエージェントを実際の業務フローに組み込み、「成果が出るまで」を一気通貫で推進することが役割の核心です。 従来のソフトウェアエンジニアとの違いは「配備場所」にあります。FDEは現場の業務担当者と並走しながらAIシステムを実装・調整します。 なぜ今重要なのか AIエージェントは「自律的にタスクを推論して実行する」という強力な特性を持っています。しかし、以下のような課題から、現場での機能不全が起きがちです。 業務ルールの複雑性: 現場の暗黙知や例外ルールをAIに正しく反映するのは困難 人間との役割分担設計: どこまでをAIに任せ、どこから人間が承認・介入するかの線引き 段階的な信頼構築: いきなり全自動化するのではなく、徐々にAIへの委任範囲を広げるプロセス管理 FDEは「現場とAIエージェントの橋渡し」を担うコア人材として必要とされています。技術力だけでなく、業務理解力・コミュニケーション力・推進力を兼ね備えることが求められます。 なぜAIではとくに「現場常駐型」が要るのか 従来の業務システムは「仕様通りに動くこと」が正解でした。これに対しAIは、データの質や現場の環境条件に大きく依存するという性質を持ちます。 現場の熟練者が持つ暗黙知はデータ化されていない 需要予測AIは入力データの欠損に左右される 画像認識(カメラ)AIは照明などの環境条件で精度が変わる これらの要素は、会議室や開発拠点にいるだけでは把握できません。FDEは現場に身を置くことで、開発と現場のあいだに生じる時間差・認識差を最小化します。違和感が出たらその場で修正し、翌日には改善版を届ける——この高速なフィードバックループこそが、AIを「実験」から「現場で使える戦力」へと進化させます。 従来のITコンサル・SEとの違い AI推進体制を検討すると、FDEはITコンサルタントやシステムエンジニア(SE)と混同されがちです。しかし主戦場も付加価値も異なります。AIプロジェクトでは「最初から正解の仕様が存在しない(都度、仕様が変わっていく)」ことが一般的で、FDEは仮説検証を短いサイクルで回しながら最適解を探索する点が決定的に違います。 観点 ITコンサルタント 従来のSE/ベンダー FDE 主な役割 戦略立案・要件定義 仕様書に基づく開発・保守 現場課題の特定と即時実装・定着 主戦場 会議室(経営・管理層) 開発拠点(リモート中心) 現場(フロントライン) 開発手法 設計書作成が中心 ウォーターフォール型 超高速アジャイル・プロトタイピング 付加価値 論理的な正解の提示 安定したシステムの構築 現場での実用性とROIの最大化 FDEが現場で担うこと AIエージェント導入の現場では、FDEは次のような多面的な役割をこなします。 フェーズ FDEの仕事 要件把握 現場に入り込み、暗黙知や例外ルールを含む業務フローを理解する 実装・調整 AIエージェントを実際の業務システムに組み込み、現場のデータで動かす ガードレール設計 どこから人間が承認・介入するか(Human-in-the-loop)の線引きを設計する 信頼構築 委任範囲を段階的に広げ、現場が安心してAIを使える状態をつくる ポイントは、単にAIにタスクを委任して終わりにしないことです。人間が最終判断するガードレールを設計し、職員・現場担当者が自らAIワークフローを調整できる仕組みを残すことが、定着するAIエージェント導入の条件になります。 高リスク環境ほど価値が出る 審査・規制・安全監視のような「間違いが許されない」高リスク業務ほど、いきなりの全自動化はできません。だからこそ、現場の複雑なルールを理解しながらAIを少しずつ組み込み、人間の監視を組み込んだ形で運用に乗せていくFDEの役割が効いてきます。段階的な導入とガードレール設計こそが、こうした環境でのAI活用を成功させる鍵です。 なぜ今、FDEが求められるのか AI投資が活発化するなか、FDEが戦略的に重要視される理由は大きく3つあります。 「使われないAI」を防ぎ、ROIを最大化する: AI導入の最大リスクは、数千万円規模の投資をしても現場で使われなくなることです。「入力が煩雑」「通知が遅い」「画面が見づらい」——こうした小さな不満がAI定着を阻みます。FDEは現場ユーザーの声を即座に反映し、UI/UXをその場で改善します。 データ品質の課題を現場で解決する: AIの精度はデータに依存しますが、基幹システムのデータが現場の実態を正確に反映していないケースは少なくありません。FDEはデータ生成のプロセスを現場で確認し、必要なら収集方法や入力フロー自体を再設計します。 意思決定から実装までのリードタイムを短縮する: 「現場要望 → 実装 → テスト → 改善」のサイクルが、数週間単位から数日、場合によっては数時間単位へと短縮されます。このスピードがDX推進の成否を左右します。 FDEに求められる3つのスキル FDEとして成果を出すには、技術と業務をまたぐ複合的な力が求められます。 ...

2026年5月26日 · 1 分

Claude Platform on AWS セットアップと API 呼び出し実録 — API key/SigV4 認証と inference_geo の挙動

2026年5月11日に一般提供(GA)となった Claude Platform on AWS のセットアップ手順・API 呼び出し・inference_geo の挙動を実機で検証した記録です。 概念的な概要や Amazon Bedrock との比較についてはこちらの記事をご参照ください。本記事では hands-on のセットアップと API 呼び出しに絞って解説します。 参考: Claude Platform on AWS がGA。セットアップとAPI呼び出しを試してみた | DevelopersIO Claude Platform on AWS とは(概要) AWS アカウントを通じて Anthropic のネイティブ Claude Platform に直接アクセスできるサービスです。Amazon Bedrock とは別サービスで、推論は Anthropic のインフラ上で実行されます。 項目 Claude Platform on AWS Claude on Bedrock 推論の実行 Anthropic AWS 利用可能な機能 全ネイティブ機能(Skills, Code Execution, Files API, MCP 等) Bedrock が提供する機能(Guardrails, KB, Converse API 等) 新機能の利用 Anthropic と同日 AWS が対応したとき 認証 AWS IAM AWS IAM 監査ログ CloudTrail CloudTrail 課金 AWS 請求に統合 AWS 請求に統合 向いているケース 最新機能・エージェント・スキル データ所在地優先・FedRAMP/HIPAA 等のコンプライアンス対応・AWS 単独データ処理要件 セットアップ手順 1. AWS コンソールで開始 AWS マネジメントコンソールで「Claude Platform on AWS」を開き「Get Started」をクリックします。確認画面で「Continue」を選択します。 ...

2026年5月22日 · 3 分

grill-me — コードを1行も書く前にAIに徹底的に詰められる、最も人気の Claude Code スキル

grill-me とは何か mattpocock/skills は、Total TypeScript で知られる Matt Pocock が自分の ~/.claude/skills/ から実際に使っている 23 本のスキルをそのまま公開したリポジトリだ。「教材向けに整えた」ではなく「本番運用している実物」というのが特徴で、X(旧 Twitter)でも注目を集めている。 その中でも最も人気が高いのが /grill-me だ。スキルの定義は英文 4 文だけ。しかしこの短さが本質で、「コードを 1 行も書く前に AI があなたを徹底的に詰める」という仕組みを実現する。リポジトリには engineering・productivity・misc の 3 カテゴリにわたる 18 本以上のスキルが収録されている。 実際のスキル定義(skills/productivity/grill-me/SKILL.md)は次のとおり: 1 2 3 4 5 6 7 Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer. Ask the questions one at a time. If a question can be answered by exploring the codebase, explore the codebase instead. なぜ「詰め」が必要なのか 生成 AI にコードを書かせる際の最大の落とし穴は、曖昧なまま走り出すことだ。「なんとなくこういうのを作りたい」で投げると、それらしいコードは出てくるが、後から要件とのズレが発覚して作り直しになる。 ...

2026年5月22日 · 2 分

「同僚.skill」が本当に変えるのは引き継ぎではない — 企業は「判断様式」を資産化し始める

GitHub で急速に広がっている colleague-skill(titanwings/colleague-skill)というプロジェクトがある。「辞めた同僚を AI で再現する」という見た目のインパクトだけが先行しがちだが、実装を読むと本質はもっと実務的だ。このプロジェクトが企業と個人に突きつけているのは、**「判断様式そのものを組織資産にできる時代が来た」**という問いだ。 colleague-skill とは何か titanwings/colleague-skill は、退職した同僚・前任者・メンターの仕事の進め方や話し方を、AI エージェントが呼び出せる Skill として保存するプロジェクトだ。 2026年5月時点で 18,000 stars 超、1,800 forks という数字が、この関心の高さを物語っている。 ポイントは新しいモデルを訓練しているわけではないことだ。人の暗黙知・レビュー癖・判断基準・口調を、Claude Code などで即座に呼び出せるパッケージに変換している。引き継ぎで失われがちな仕事の文脈を、実際に動く形で残すことが目的だ。 入力できるもの Feishu・DingTalk・Slack・WeChat の会話履歴、PDF、画像、メール、Markdown、手入力テキストなど幅広いソースに対応している。 Claude Code への組み込み インストールは軽量だ。 1 2 3 # ターミナルで実行 cd ~/.claude/skills git clone https://github.com/titanwings/colleague-skill . その後、Claude Code 上でスラッシュコマンドを実行する。 /create-colleague .claude/skills/ に配置して /create-colleague を実行するだけで、対話形式でスキルが生成される。 二層構造の設計:Work Skill と Persona README の設計で最も重要なのは、生成物が二つのレイヤーに分かれていることだ。 レイヤー 内容 Work Skill 担当システム、技術スタック、レビュー観点、文書作法、運用フロー、経験知 Persona 話し方、優先順位、判断癖、対人スタイル、地雷 実行順序まで定義されている。 ...

2026年5月21日 · 3 分

Skills vs Agents — Anthropic の研究チームが設計哲学を全転換した理由と Claude Code 実践ガイド

Anthropic の研究・プロダクトチーム(Barry Zhang・Mahesh Murag)が、2025年11月の AI Engineering Code Summit で衝撃的な発言をした。 「Agents をやめて、Skills に全振りした」 Agent ツールを実際に開発してきた当事者が、この言葉を口にした意味は重い。単なる命名変更ではなく、AI 自動化の設計哲学そのものが変わった瞬間だ。 この記事では、なぜ Anthropic が Agents から Skills へシフトしたのか、その背景と技術的な理由、そして今すぐ自分のワークフローに活かせるポイントを解説する。 Agents の限界 — 何が問題だったのか 従来の「Agent」アプローチの核心は、中央集権型オーケストレーターだった。1 つの LLM が多数のツールを持ち、あらゆるタスクに対応しようとする構成だ。具体的には以下の 4 点が問題になった。 ツールオーバーロード: ツール数が増えるほど、LLM はどのツールを使うべきか判断しにくくなる 再現性の低さ: 複雑なシナリオで中央オーケストレーターが混乱し、同じ入力に対して異なる結果が出やすい モデル依存: Claude 専用に設計された Agent は、他のモデルでは動かない コンテキスト肥大化: すべての能力を一度にロードするため、トークンが無駄に消費される Barry Zhang と Mahesh Murag はこれらの問題を実装レベルで体験し、「根本から再設計が必要だ」という結論に至った。 Skills とは何か — Agent との本質的な違い Skills は、Claude Code の拡張機能の単位だ。SKILL.md と必要なスクリプト・設定ファイルを 1 つのフォルダにまとめて定義し、必要なときだけオンデマンドでメイン会話コンテキストに注入される。 観点 Agents Skills 設計思想 中央集権型オーケストレーター モジュラー・再利用可能な能力単位 モデル対応 Claude 専用 Claude + 他モデル両対応 実行コンテキスト 独立した隔離環境 メイン会話内(記憶・フォローアップが可能) ロード方式 常時ロード オンデマンド(トークン節約) 再現性 複雑なシナリオで低下しやすい 実用レベルで高い 最も重要な変化はモデル非依存になったことだ。Anthropic は 2025年12月に Skills をオープンスタンダードとして agentskills.io で公開し、Microsoft/VS Code・OpenAI・Cursor・GitHub・Google Gemini CLI・JetBrains Junie など主要プラットフォームが採用済みだ。Claude だけでなく、他のモデルでも同じスキルが動作する。 ...

2026年5月21日 · 1 分

「Claudeだけで6500万ドル」バイラル投稿の真相と、AIコンテンツ自動化の現実

この記事では、147万ビューを集めたバイラル投稿の信憑性をコミュニティノートとともに検証し、AIコンテンツ自動化の現実的なスケールを整理する。 バイラル投稿の概要 2026年5月、X(旧Twitter)でこんな投稿(トルコ語、以下意訳)が拡散した。 ロサンゼルスに住む7人の若者が、Claudeだけを使ってeブックを販売し、合計6500万ドル(約95億円)を稼いだ。なぜか誰もこれを話題にしていない。 従業員なし。オフィスなし。大学卒業者ひとりもいない。Claudeで1日わずか45秒で300本のコンテンツを生成し、1500万以上のオーガニックビューを獲得。 でも彼らは毎日何百ものコンテンツを手動で投稿していたわけではない。 代わりに、あるシステムを構築した:Claude + コンテンツ生成フロー + 完全自動化システム この投稿は147万以上のビューを記録し、4000件以上のいいね、9500件以上のブックマークを集めた。 コミュニティノートの警告 しかし、この投稿にはコミュニティノートが付いている。 ロサンゼルスに住む7人の若者がClaude eブック販売で6500万ドルを稼いだという主張は、独立した情報源によって検証されていません。このストーリーはマーケティング目的のXの投稿にのみ存在します。 要するに、この主張は裏付けがない。公式な財務報告も、独立した報道も存在しない。「誰かがバイラルを狙って作り上げた話」である可能性が高い。 こうした「AIで億万長者」系の投稿は定期的に出回るが、その多くはコンサルティングやコース販売への誘導が目的だ。実際、この投稿の最後も「どうやってやったか説明します」という続きがある構造になっている。 ではAIによるコンテンツ自動化は嘘か? しかし、自動化そのものは実在する技術だ。 ただし、現実的なスケールの話として捉え直す必要がある。 Claudeなどの大規模言語モデルを使ったコンテンツ生産の自動化は、実際に多くの企業や個人が取り組んでいる分野だ。正確には以下のような流れになる。 典型的なコンテンツ自動化パイプライン テーマ選定 — トレンドキーワードのスクレイピング、競合分析、ニッチ市場の需要調査 コンテンツ生成(Claude API) — アウトライン生成、各章の本文生成、タイトル・見出しの最適化、SEO向けキーワード埋め込み レビュー・品質チェック — ファクトチェック、読みやすさのスコアリング、重複チェック 配信・販売 — Amazon KDP / Gumroad への自動アップロード、SNSへの告知コンテンツ自動生成、メールマーケティングとの連携 現実的な成果スケール 1日300本の「コンテンツ」:短いSNS投稿なら不可能ではないが、品質管理が追いつかない 45秒でeブック1冊:完成品は難しい。アウトラインや章の一部なら可能 6500万ドル:eブックのみでこの売上は極めて異例。多くのメガ出版社でもこの規模は数年かかる 実際にAIコンテンツ自動化で成功している事例は存在するが、月収数百万円〜数千万円規模が現実的なトップライン。「6500万ドル」は検証されていない数字だ。 Claude APIを使った実際のeブック自動化 現実的な範囲でClaudeを活用するとしたら、以下のようなアプローチが有効だ。 シンプルなeブック生成スクリプト 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 import anthropic client = anthropic.Anthropic() def generate_ebook_outline(topic: str) -> str: message = client.messages.create( model="claude-opus-4-7", max_tokens=2048, messages=[ { "role": "user", "content": f"""以下のトピックについて、商業用eブックのアウトラインを作成してください。 トピック: {topic} 要件: - 章数: 7〜10章 - 各章に2〜3のサブセクション - 実践的な内容を重視 - 読者ターゲットを明確に Markdown形式で出力してください。""" } ] ) return message.content[0].text def generate_chapter(outline: str, chapter_title: str, word_count: int = 1500) -> str: message = client.messages.create( model="claude-opus-4-7", max_tokens=4096, system="あなたはプロのライターです。実践的で価値のあるコンテンツを書いてください。", messages=[ { "role": "user", "content": f"""以下のeブックの章を執筆してください。 全体アウトライン: {outline} 執筆する章: {chapter_title} 目標文字数: 約{word_count}文字 具体例や実践的なアドバイスを含めてください。""" } ] ) return message.content[0].text プロンプトキャッシュを活用した効率化 大量生成する場合は、プロンプトキャッシュを活用するとコストを大幅に削減できる。 ...

2026年5月20日 · 2 分

「白いユニフォームの選手を追え」— Meta SAM3 がスポーツスカウティングを一変させる仕組み

概要 2026年5月20日、スペイン語圏のテックメディア @CopyRebeldia が衝撃的なポストを投稿した。 「今日、業界ひとつまるごと意味を失った。Meta が SAM3 を GitHub で公開した。『白いユニフォームの選手』と言うだけで、NBA の混戦の中からその選手だけを追跡し、戦術図まで重ね描いてくれる。手動スカウティングはもう趣味になった。」 このデモ動画を投稿したのは Roboflow のオープンソースリード Piotr Skalski(@skalskip92)。わずか 19 秒の映像が、コンピュータビジョン界隈に大きな波紋を呼んだ。 本記事では Meta SAM3 の仕組みと、スポーツ分析をはじめとする実用分野への影響を解説する。 SAM3 とは SAM3(Segment Anything Model 3) は Meta AI Research が開発したモデルだ。画像・動画を対象に、物体の検出・セグメンテーション・追跡を一つのモデルに統合している。 公開日: 2025年11月19日(SAM 3.1 は 2026年3月27日) GitHub: facebookresearch/sam3 論文: SAM 3: Segment Anything with Concepts 前世代の SAM2 と比べた最大の変化は「テキストプロンプトで物体を指定できる」点だ。 SAM2 との違い SAM2 SAM3 プロンプト形式 点・ボックス・マスク(空間的) テキスト・サンプル画像・空間的 セマンティック理解 なし あり(オープン語彙) 複数物体追跡 品質低下あり Object Multiplex で並列追跡(3.1〜) 言語エンコーダ なし 大規模テキストエンコーダ統合 カモフラージュ物体 検出困難 検出可能 SAM2 は「この座標にある物体を追え」という指示しかできなかった。SAM3 は「白いユニフォームを着た選手」「ボールを持っている人」という意味的な概念で物体を特定できる。 ...

2026年5月20日 · 1 分

Anthropic 社員が使う implementation-notes プロンプト — 計画レビューとの違いと AI 時代の監査レイヤー論

AIに「作らせる」だけでは足りない時代 AIコーディングツール(Claude Code、Codex、Cursor など)を使う際、多くの開発者が次のプロンプトで止まってしまっている。 1 2 3 「作って」 「修正して」 「いい感じにして」 これで機能は動く。しかし、後から「なぜそうなったのか」が一切わからない。 Claude Code Studio(@ClaudeCode_love)が紹介した、Anthropic 社員が使っているとされるプロンプトは、その問題に真正面から切り込んでいる(公式声明ではなく、あくまで伝聞である点に注意)。 Anthropic 社員が使うプロンプト 元ツイート(2026-05-19)では「自分がいちばん使っているプロンプト」として次の指示が紹介されている。 1 2 3 仕様書通りに実装して。 その途中で、仕様書に書かれてなかった判断・変更・妥協点・意思決定を、 全部 implementation-notes に残して 英語で書くなら次のようになる。 1 2 3 Implement according to the specification. Along the way, record every judgment, change, trade-off, and decision not covered by the spec into implementation-notes. 一見地味に見えるが、これは AI コーディングの本質を突いたプロンプトだ。本記事では、このプロンプトを 「計画レビュー」と対比する形で深掘り し、なぜ AI コーディング時代に implementation-notes パターンが支配的になるのかを考察する。 ...

2026年5月20日 · 4 分

OpenHuman — 完全ローカルで動くパーソナルAIアシスタント:プライバシー最優先でChatGPT級の体験を自分のPCで

2026-05-27 追記: 実際にインストールしてみたところ、デフォルトのままでは TinyHumans へのサブスク課金(=有料アカウント)が必要なことが判明した。GPL-3 のオープンソースなのになぜ有料なのか、本記事に「なぜ TinyHumans への課金が必要なのか」セクションを追加した。「完全ローカル」を額面どおりに実現するための回避ルートも併記している。 「クラウドAIに自分の悩みを打ち明けるのが不安」という声をよく聞く。仕事の機密、家族の話、健康上の悩み——ChatGPTに投げてはみるものの、その会話がサーバーに残り続けることへの抵抗感は根強い。 そこに登場したのが OpenHuman だ。GitHubスター数2.7万を超え、週に1,000以上のペースで増え続けるこのプロジェクトは、「ChatGPT級のAIを完全にローカルで動かす」という問いへの実践的な回答を提供している。 OpenHumanとは OpenHuman は、TinyHumans AIが開発するオープンソースのエージェント型AIアシスタントだ。Rustをコアに持ち、デスクトップアプリとして動作する。 公式の説明は簡潔にまとめられている。 Your Personal AI super intelligence. Private, Simple and extremely powerful. ポイントは3点だ。 Memory Tree による長期記憶 Obsidianスタイルのローカルナレッジベース 118以上のサービス連携 これらを組み合わせることで、「インストールから数分でユーザーを知り尽くしたエージェント」を目指している。 なぜ「ローカルAI」が重要なのか ChatGPTをはじめとするクラウドAIの課題は、会話が外部サーバーへ送信される点にある。個人情報保護の観点から問題となるだけでなく、企業での利用では情報漏洩リスクが伴う。 OpenHumanが解決しようとしているのはこの点だ。 会話を外に出さない構成が選べる — ローカルLLM(Ollama / LM Studio経由)を選択すれば推論まで自機で完結する データは自分のPCに保存される — Memory Tree DB と Markdown Vault はローカルファイルとして残る 日本語README完備 — 日本語ユーザーへの配慮も行き届いている Rust製で爆速 — コアがRustで書かれており、動作が軽快 ただし注意点がある。デフォルト構成では「サインイン」「モデルルーティング」「Web検索プロキシ」「Composio経由のOAuth/ツール連携」がすべてOpenHuman(TinyHumans)社のマネージドバックエンドを経由する。つまり初回起動時に TinyHumans アカウントを作って有料サブスクに入らないと、せっかくのMemory TreeもAuto-fetchも動かない。「完全オフライン」を額面どおりに実現するには、ローカルモデル+Composio直接モード+自前のWeb検索APIキー、といった追加設定が必要になる。詳細は後述する。 主な機能 Memory Tree + Obsidian Vault OpenHumanの中核機能は Memory Tree だ。接続した各種サービスから取得したデータを3,000トークン以内のMarkdownチャンクに圧縮し、SQLiteに階層的に保存する。同時に、Obsidianと互換性のある .md ファイルとしてローカルVaultへ書き出す。 ...

2026年5月20日 · 3 分