AI/LLM

「OpenClawを使うにはMac miniが必要」という誤解が広まっているが、実際には1500円程度の小型基板でも十分に動作する。本記事では、OpenClawの設計と課題を整理したうえで、超軽量な後継インフラ「NullClaw」を使ってAI組織を低コストで構築する方法を解説する。 1. AIエージェントインフラの変遷 AIの進化は単なるテキスト生成から「自律的な行動」へと移行している。ChatGPT等のLLMは問いに対して答えを返すことに特化していたが、実際の業務では情報の整理、メール送信、資料作成、定期タスクの実行といった「具体的な行動」が求められる。 これを実現するのが「AIエージェント」という概念だ。エージェントは外部のAPI、ファイルシステム、データベース、物理デバイスと連携して動作し、自ら道具（ツール）を使いながら目的を達成するステップを組み立てる。 複数のプラットフォーム（Slack、Discord、LINE、Webアプリ等）から同じAIを一貫して呼び出すための基盤として登場したのが、OpenClawをはじめとするエージェント実行基盤だ。 2. OpenClawの設計思想と課題 2.1 マルチチャネル対応の共通基盤 OpenClawは中央に「エージェント実行エンジン」を置き、各プラットフォームを「ゲートウェイ」として接続するアーキテクチャを採用している。一度エージェントのロジックを記述すれば、あらゆるチャネルで再利用できる。 2.2 アーキテクチャ構成 TypeScript / Node.js ベースで実装されており、主に以下のコンポーネントで構成される。 ゲートウェイ層 — 各メッセージングアプリからの入力を共通フォーマットに変換 ランタイム層 — LLM（OpenAI、Anthropic等）と通信してエージェントの思考を制御 ツール層 — Google検索、Python実行、ファイル操作などの具体的なアクションを定義 セッション・状態管理 — 会話履歴や実行中タスクの状態を保持 2.3 運用の課題 OpenClawは高い柔軟性を持つ一方で、実運用での課題が浮き彫りになった。 リソース消費: Node.js 環境では数GB のRAMを消費することがある。安価なVPSやシングルボードコンピュータでの常駐には重すぎる 起動速度（コールドスタート）: Node.js のランタイム起動に数秒〜十数秒かかり、リアルタイム対話サービスでは致命的な遅延になる 依存関係の複雑さ: 数千の外部パッケージ（node_modules）に依存し、バージョン不一致やセキュリティ脆弱性のリスクが高い これらの課題はOpenClawが「汎用的な基盤」を目指した結果の宿命的な側面でもある。この限界を突破するために登場したのが、Zig言語で再実装された「NullClaw」だ。 3. NullClaw：次世代の超軽量インフラ 3.1 Zig 言語採用の理由 NullClaw はシステムプログラミング言語「Zig」を採用している。Zigは C 言語の代替を目指し、メモリ管理の明示性、依存関係の極小化を重視して設計されている。 採用の主な技術的メリットは以下の3点だ。 メモリ管理の透明性 — ガベージコレクション（GC）なし。メモリの割り当てと解放を開発者が明示的に制御するため、予測不可能なGCポーズを排除し、安定した低メモリフットプリントを実現 静的バイナリの生成 — 外部の共有ライブラリやインタープリタ不要。単一の実行可能ファイルを配置するだけで動作 安全性の担保 — 境界チェックや未定義動作の検出が組み込まれており、メモリ破壊やバッファオーバーフローを防止 3.2 OpenClaw vs NullClaw 比較 比較項目 OpenClaw NullClaw 主要言語 TypeScript (Node.js) Zig (Native) バイナリサイズ 数百MB（ランタイム込） 約678 KB メモリ使用量 数百MB〜数GB 約1 MB 起動速度 数秒〜十数秒 2ms以下 依存関係 node_modules（膨大） ほぼゼロ（libcのみ） 配布形態 パッケージ/コンテナ 単一バイナリ 起動速度「2ms以下」は、ユーザーがAIを呼び出した瞬間に処理が開始されることを意味する。オンデマンド実行において圧倒的な優位性だ。 ...

DAIJOBU CEO の山中裕貴（@0xfene）氏が、Claude Code のカスタムスキル機能を営業業務に活用し、商談準備を劇的に効率化した事例を紹介している。 従来の商談準備の課題 営業担当者の商談サイクルには、以下のような時間のかかるタスクが含まれる： 商談前: 30分〜1時間かけて Gmail・Slack・議事録ツールから過去のやり取りを手動で情報収集 商談中: 準備不足で焦ることがある 商談後: 15〜20分かけてフォローメールを作成 Claude Code スキルによる自動化 山中氏は Claude Code のスキル機能（.claude/skills/ 配下にプロンプトを定義する仕組み）を使い、営業ワークフロー全体を自動化した。 /mtg-prep — 商談準備の自動化 /mtg-prep コマンドを実行すると、複数の AI エージェントが並行稼働し、以下の情報を 2〜3分で収集・整理する： 過去のやり取り: Gmail、Slack、Circleback（AI 議事録サービス）から顧客との過去のコミュニケーションを取得 顧客調査: 企業情報、業界動向のリサーチ 競合調査: 競合他社の状況を自動調査 提案ドラフト: 確認事項、提案の方向性、想定質問、フォローアップのアクションプランを整理 結果はマークダウンファイルとしてローカルに保存される。 /follow-up — 商談後フォローの自動化 商談終了直後に /follow-up コマンドを実行すると、商談の内容を踏まえたフォローメールが 2〜3分で自動生成される。記憶が鮮明なうちに具体的な内容を含んだメールを送れるのがポイントだ。 /export-gdoc — ドキュメント共有 作成されたマークダウンファイルを Google ドキュメントに変換し、Notion スタイルの統一されたデザインで社内共有やクライアントへの提案に活用できる。 導入効果 山中氏によると、Claude Code 導入後は 体感で 3〜5倍の商談量を品質を下げずに捌ける ようになったという。 項目 導入前 導入後 商談準備 30分〜1時間 2〜3分（/mtg-prep） 商談中 準備不足で焦る場面も 相手の話に集中できる フォローメール 15〜20分 2〜3分（/follow-up） Claude Code スキルの仕組み Claude Code のスキル機能は、プロジェクトの .claude/skills/ ディレクトリにマークダウンファイルとしてプロンプトを定義する。/スキル名 でスラッシュコマンドとして呼び出せるため、営業担当者でも簡単に利用できる。 ...

AIエージェントが単独で動く時代から、複数のエージェントが協調して動く時代へ移行しつつある。エージェント間の通信を設計するとき、「会話（何を話すか）」と「transport（どう届けるか）」を分離する考え方が重要になっている。本記事では、2026年に整備が進むエージェント間通信プロトコルの全体像と、Relay基盤のアーキテクチャを整理する。 なぜ「会話」と「transport」を分離するのか AIエージェント同士が会話する際、2つの関心事が混在しがちだ: 会話層: タスクの依頼、進捗報告、結果の返却といった「意味のあるやりとり」 transport層: HTTP、gRPC、WebSocket、SSE といった「届ける仕組み」 これらを密結合にすると、transport を変更するたびに会話ロジックを書き直す必要が生じる。たとえば、開発時は HTTP で通信していたエージェントを、本番では gRPC に切り替えたいケースや、ローカルの関数呼び出しからリモートの API 呼び出しに切り替えたいケースがある。 分離することで、エージェントのビジネスロジック（会話）は transport に依存せず、transport の差し替えが容易になる。 2026年のエージェント間通信プロトコル 現在、エージェント通信の標準化が急速に進んでいる。主要なプロトコルは以下の通り。 MCP（Model Context Protocol） Anthropic が策定したプロトコルで、エージェントと外部ツール/リソースの接続を標準化する。API、ファイルシステム、データベースへのアクセスを統一的なインターフェースで提供する。 役割: ツール・コンテキスト層 transport: RESTful サーバー経由の構造化データ交換 エージェント → MCP サーバー → 外部ツール（DB, API, ファイル） A2A（Agent-to-Agent Protocol） Google が主導し、50社以上のパートナーが参加するオープン標準。エージェント同士のピアツーピア通信とタスク委譲を実現する。 役割: エージェント間通信層 transport: HTTPS 上の JSON-RPC 2.0 + SSE（ストリーミング） 通信モデル: クライアントエージェント → リモートエージェント クライアントエージェント ──JSON-RPC──→ リモートエージェント ←──SSE──── A2A の特徴は、エージェントの内部メモリ、ツール、ロジックを共有せずに協調できる点。発見（Discovery）→ 認可（Authorization）→ 通信（Communication）の3段階で動作する。 ACP（Agent Communication Platform） REST ベースの通信とエージェントレジストリを組み合わせたプラットフォーム。 役割: レジストリ駆動の通信基盤 transport: REST インターフェース 特徴: ステートフルなメッセージルーティングでコンテキストを保持 ANP（Agent Network Protocol） インターネット規模のエージェント協調を想定したプロトコル。 ...

SEO・コンテンツマーケティングの専門家 Jake Ward 氏が、AI とプログラマティック SEO を組み合わせて 60日間で SEO トラフィックを466%（5.7倍）増加 させた手法が注目を集めています。13,000ページ以上をわずか3時間で生成し、週間オーガニッククリックを971から5,500に伸ばした具体的なアプローチを解説します。 成果の概要 13,000+ ページを3時間で生成 週間オーガニッククリック: 971 → 5,500（+466%） 60日間で達成 従来のプログラマティック SEO との違い 従来のプログラマティック SEO は、テンプレートの単語を置換するだけのものが多く、低品質なページが量産される問題がありました。Jake Ward 氏のアプローチは、AI にフリーフォームでコンテンツを書かせるのではなく、厳密な JSON Schema を埋め込むことで品質を担保しています。 3つの核心ポイント 1. JSON Schema によるコンテンツ構造化 最も重要な技術的要素が、AI への指示に厳密な JSON Schema を使うことです。 1 2 3 4 5 6 7 8 9 10 11 12 13 { "section_title": "string", "items": [ { "name": "string", "description": "string (50-100 words)", "difficulty_level": "beginner | intermediate | advanced", "potential_score": "number (1-10)" } ], "min_items": 15, "max_items": 20 } AI にフリーフォームの文章を書かせると、ページごとに品質がばらつきます。JSON Schema で出力形式を固定することで、13,000ページ全体で一貫した品質を維持できます。 ...

Anthropic が Claude Code にリサーチプレビューとして「Auto Mode」を導入しました。claude --permission-mode auto で起動すると、ツール使用の許可判断を Claude 自身が行い、開発者の手動承認なしで長時間の連続作業が可能になります。 Auto Mode とは 従来の Claude Code では、ファイルの書き込みやシェルコマンドの実行のたびに許可プロンプトが表示されていました。これは安全性の面では重要ですが、長時間のタスクでは開発フローが頻繁に中断される原因になっていました。 Auto Mode はこの問題に対処するもので、各操作について Claude 自身がリスクを判断し、安全と判断した操作は自動で承認します。 使い方 起動時にフラグを指定します: 1 claude --permission-mode auto または、セッション中に Shift+Tab で許可モードを切り替えることもできます。 既存の許可モードとの比較 Claude Code には複数の許可モードがあります: モード 動作 Normal 操作ごとに許可を求める（デフォルト） Auto-accept edit ファイル編集は自動承認、シェルコマンドは確認 Auto Mode Claude がリスク判断して自動承認（新機能） Plan 読み取り専用、変更は一切行わない Auto Mode は --dangerously-skip-permissions のような全許可フラグとは異なり、Claude がリスク分類を行った上で判断するため、安全性と利便性のバランスを取ったアプローチです。 セキュリティ上の注意点 Auto Mode は万能ではありません。Anthropic は以下の点を注意喚起しています: 隔離環境での使用を推奨: 本番環境の認証情報やライブ API へのアクセスがあるマシンでは使わない プロンプトインジェクション対策: ファイルやコマンド出力内の悪意ある指示から保護する機能を搭載 トークン使用量の増加: リスク判断のオーバーヘッドにより、若干のコスト・レイテンシ増加がある 組織での管理 IT 管理者は Auto Mode を制限することもできます: ...

Claude Code の Skills 機能を使って、過去のプロンプト入力履歴をスキャンし、利用者が「何を分かっていて、何を分かっていないか」を可視化する仕組みが紹介されていました。プロンプトを通じた新人教育の可能性を探ります。 アイデアの概要 @tokoroten氏のポストで紹介されたアプローチは以下の通りです: Claude Code の Skills を利用して、過去のプロンプト入力履歴をスキャンする その履歴から、利用者が何を理解していて、何を理解していないかを分析・出力する 結果として、どの技術分野の理解が甘いかが可視化される これにより、プロンプトを通じた新人教育が可能になる Claude Code Skills とは Claude Code の Skills は、再利用可能なプロンプトテンプレートをプロジェクト内に定義できる機能です。.claude/skills/ ディレクトリにスキル定義を配置することで、/スキル名 のようなスラッシュコマンドとして呼び出せます。 .claude/ skills/ analyze-prompts/ skill.md # スキルの定義・プロンプト スキルには以下のような特徴があります: プロジェクト固有のワークフローを定義できる 引数を受け取ることが可能 複数のツール呼び出しを組み合わせた複雑な処理を自動化できる プロンプト履歴から理解度を分析する仕組み このアプローチの面白いところは、プロンプト（質問）の内容自体が「その人が何を知らないか」の強力なシグナルになるという点です。 分析の観点 質問の頻度: 特定の技術領域について繰り返し質問しているなら、その分野の理解が浅い可能性が高い 質問の深さ: 基本的な概念を聞いているのか、応用的な質問をしているのかで理解度が測れる 自己解決率: 同じトピックの質問が減っていれば、学習が進んでいると判断できる 教育への応用 従来の新人教育では、メンターが1対1でレビューしたり、定期的な面談で理解度を確認したりする必要がありました。このアプローチでは: 受動的な観察: 普段の業務でのプロンプト利用を分析するだけで、能動的なヒアリングが不要 定量的な評価: どの分野にどれだけ質問しているかを数値化できる 継続的なトラッキング: 時系列での成長を追跡できる 実現に向けた考慮点 このような仕組みを導入する際には、いくつかの点を考慮する必要があります。 プライバシーへの配慮 プロンプト履歴には業務上の機密情報が含まれる可能性があるため、分析対象の範囲や匿名化の方法を検討する必要があります。 分析精度の担保 単純なキーワードマッチだけでは正確な理解度評価は難しく、文脈を考慮した分析が求められます。Claude Code 自体の言語理解能力を活かすことで、より精度の高い分析が可能になるでしょう。 フィードバックループの構築 分析結果を本人にフィードバックし、推奨学習リソースを提示するところまで自動化できれば、より実用的な教育ツールになります。 まとめ Claude Code の Skills を活用したプロンプト履歴分析は、AI ツールの利用ログそのものを教育データとして活用するという発想です。新人が日常的に AI に質問する行為自体が、自然と学習進捗の記録になるというのは、AI 時代ならではの教育アプローチと言えます。

Claude Code で Markdown や JSON ファイルを直接編集してデータ管理を行うのは、少量のデータなら問題ありません。しかし、レコード数が100件を超えるような規模になると、スキーマ違反や細かいスクリプト制御の問題、パフォーマンスの低下が発生しやすくなります。こうした場面では、SQLite や DuckDB を活用するのが効果的です。 Markdown/JSON 直接編集の限界 Claude Code にMarkdown ファイルや JSON ファイルを直接編集させる方法は、手軽で分かりやすい反面、データ量が増えると以下の問題が顕在化します。 スキーマ違反: JSON の構造が崩れたり、必須フィールドが欠落するケースが発生する 細かいスクリプト制御が必要になる: データの整合性を保つために、バリデーションや変換のスクリプトが増えていく パフォーマンス低下: ファイル全体を読み込んで書き戻す処理が、レコード数に比例して遅くなる SQLite を使うメリット SQLite はファイルベースの軽量データベースで、Claude Code との相性が良好です。 1 2 3 4 5 6 # SQLite データベースを作成してテーブルを定義 sqlite3 data.db "CREATE TABLE items (id INTEGER PRIMARY KEY, name TEXT, value REAL);" # Claude Code から SQL でデータを操作 sqlite3 data.db "INSERT INTO items (name, value) VALUES ('example', 42.0);" sqlite3 data.db "SELECT * FROM items WHERE value > 10;" ACID準拠: データの整合性がデータベースエンジンによって保証される SQL によるクエリ: 複雑な検索・集計・更新が簡潔に記述できる 単一ファイル: .db ファイル1つで完結し、バックアップやコピーが容易 DuckDB を使うメリット DuckDB は分析用途に特化したインプロセスデータベースです。CSV、Parquet、JSON などのファイルを直接 SQL でクエリできます。 ...

LLMベースのコーディングエージェント（Claude Code、Cursor など）は、セッションが変わるたびにプロジェクトの規約や過去のミスを忘れてしまう。小さなプロトタイプなら問題にならないが、10万行を超える大規模コードベースでは「毎回同じ説明をする」「直したはずのバグパターンが再発する」といったコストが無視できなくなる。 2026年2月に公開された論文 Codified Context: Infrastructure for AI Agents in a Complex Codebase（Aristidis Vasilopoulos）は、この問題に対して 3層のメモリインフラストラクチャ を提案し、108,000行のC#分散システムを283セッションかけて構築した実践データとともに検証している。 問題：セッション間で失われる記憶 LLMエージェントは各セッションの開始時にコンテキストがリセットされる。.cursorrules や CLAUDE.md のような単一ファイルでプロジェクト規約を伝える方法は小規模なら有効だが、10万行規模のシステムでは単一プロンプトに収まりきらない。 結果として起きる典型的な問題: 命名規則やアーキテクチャパターンの逸脱 過去に修正した失敗パターンの再発 サブシステム間の整合性の欠如 提案手法：3層の Codified Context 論文では、プロジェクト知識を 負荷分散インフラストラクチャ として扱う3層アーキテクチャを提案している。 Tier 1: Hot-Memory Constitution（約660行） 常にセッションにロードされるMarkdownファイル。以下を含む: コード品質基準・命名規則 ビルドコマンド アーキテクチャパターンの要約 よくある操作のチェックリスト 既知の失敗モード（過去のバグパターン） オーケストレーション用トリガーテーブル トリガーテーブルは「どのファイルを変更したら、どの専門エージェントを呼ぶか」を定義する: ファイル変更 割り当てエージェント Network, sync network-protocol-designer Coordinates, camera coordinate-wizard UI配信 ui-sync-specialist Tier 2: Specialized Agents（19エージェント、約9,300行） タスクに応じて呼び出される専門エージェント群。2つのクラスに分かれる: 高能力エージェント（8個、平均711行）: ネットワークプロトコル設計、アーキテクチャ検証、デバッグなど 標準能力エージェント（11個、平均327行）: 特定タスクにフォーカス 各エージェント仕様の 50%以上がプロジェクト固有のドメイン知識 で構成されている。コード例、数式、失敗モードなど、そのプロジェクトでしか使えない具体的な情報が埋め込まれている点が特徴。 Tier 3: Cold-Memory Knowledge Base（34文書、約16,250行） サブシステムごとの詳細仕様をMarkdownで記述し、MCP（Model Context Protocol）検索サーバー経由でオンデマンド参照する: ...

ChatGPTやClaude、Perplexityなどの AI 検索エンジンに自社サイトを見つけてもらうための最適化ツール「geo-seo-claude」がオープンソースで公開されている。従来の SEO に加えて、AI が引用・参照しやすいコンテンツ構造を自動分析・提案してくれる Claude Code 用スキルだ。 GEO（Generative Engine Optimization）とは 従来の SEO が Google などの検索エンジンでの上位表示を目指すのに対し、GEO は AI 検索エンジン（ChatGPT、Claude、Perplexity、Gemini、Google AI Overviews）での「引用されやすさ」を最適化する考え方だ。 AI がウェブ上の情報を参照して回答を生成する際、どのサイトが引用されるかは以下のような要素に左右される： コンテンツの構造化の度合い AI クローラーへのアクセス許可（robots.txt） ブランドの権威性（各プラットフォームでの言及） スキーママークアップの品質 geo-seo-claude の主な機能 引用可能性スコアリング（Citability Scoring） コンテンツが AI に引用されやすい構造になっているかを評価する。134〜167語の最適な段落長、明確な見出し構造、事実ベースの記述かどうかなどをチェックする。 AI クローラー分析 robots.txt を解析し、14以上の AI ボット（GPTBot、ClaudeBot、PerplexityBot など）へのアクセス許可状況を確認する。ブロックしているボットがあれば、許可すべきかの推奨事項を提示する。 ブランド言及スキャン YouTube、Reddit、Wikipedia、LinkedIn など7つ以上のプラットフォームでのブランド言及を検出する。AI は複数ソースでの言及が多いサイトをより信頼性が高いと判断する傾向がある。 プラットフォーム別最適化 ChatGPT、Perplexity、Google AI Overviews それぞれの特性に合わせた最適化提案を行う。各 AI 検索エンジンがコンテンツを処理する方法は異なるため、プラットフォームごとのカスタマイズが重要になる。 llms.txt 生成 AI クローラーがサイト構造を理解しやすくするための新興標準ファイル llms.txt を自動生成する。Answer.AI の Jeremy Howard が提案した規格で、robots.txt の AI 版のような位置づけを目指している（現時点ではまだ提案段階）。 PDF レポート生成 スコアゲージ、棒グラフ、カラーコード付きテーブルなど、視覚的にわかりやすいプロフェッショナルな監査レポートを PDF 形式で出力できる。 ...

オープンソースの AI エージェント基盤 OpenClaw を使って、保有銘柄の株価アラート・決算通知・ニュース収集を自動化した実装事例を紹介します。Zenn の実践記事を元に、設計思想と実装パターンを整理しました。 個人投資家が抱える情報収集の課題 趣味で株式投資をしていると、以下の問題に直面します。 受動的な情報取得 — 自分で証券アプリを開いて確認する必要があり、変動への気付きが遅れる 情報の分散 — 株価、ニュース、決算情報が異なるサービスに散在 文脈の欠如 — 「株価が3%下がった」という事実だけでは理由がわからない 手動メンテナンス — 新規銘柄追加時に各サービスへの個別登録が必要 なぜ OpenClaw が向いているか OpenClaw は Peter Steinberger 氏が開発したオープンソースの AI エージェント基盤です。以下の特徴が情報収集の自動化に適しています。 常時起動・定期実行 — クラウド上で 24 時間稼働し、cron スケジューラーで定期タスクを実行できる LLM による文脈理解 — 単純なアラートと異なり、「何が起きたか」だけでなく「なぜ起きたか」まで Web 検索で調べて報告できる 柔軟な報告内容 — 自然言語でプロンプトに指示を書くだけで報告フォーマットをカスタマイズできる アーキテクチャ全体像 設計の核は Single Source of Truth（信頼できる唯一の情報源） です。 Google スプレッドシート（マスターデータ） ↓ portfolio-sync（毎日 6:20） portfolio.json ─→ interests.json ↓ ↓ 株価アラート ニュース収集 決算通知 週次レポート 銘柄追加・削除時はスプレッドシートを更新するだけで、下流の全システム（ニュース収集、アラート、レポート）に自動反映されます。 cron ジョブ一覧 時刻 ジョブ 内容 6:20 portfolio-sync スプレッドシート → portfolio.json 同期 毎時:30 news-auto-collect 保有銘柄関連ニュースを自動収集 7:00 morning-start 翌日決算があれば通知 10:00 portfolio-alert-am 3%以上変動でアラート 14:30 portfolio-alert-pm 3%以上変動でアラート 17:00 earnings-report 当日決算発表の結果報告 土曜 10:00 weekly-portfolio-image 週次損益レポート画像 実装パターン 1. マスターデータ管理 Google スプレッドシートに以下のカラムを用意します。 ...