AI/LLM on hdknr blog

Gemini Agentモード：Google Workspaceを丸ごと自動化するAIエージェントの実力

Tue, 07 Apr 2026 00:00:00 +0000

Google Gemini Agentモードの機能・活用事例・料金を解説。Gmail・カレンダー・Driveを横断する自動化、スケジュール実行、OpenClawとの比較まで網羅。

Gemma 4 31B vs Qwen3.5-27B — ローカルLLM最強はどちらか

Tue, 07 Apr 2026 00:00:00 +0000

Google Gemma 4 31BとAlibaba Qwen3.5-27Bをローカル実行の観点で徹底比較。ベンチマーク、メモリ要件、マルチモーダル、日本語対応、推論速度を検証する。

Gemma 4がAPI経済を破壊する — オープンモデルがSaaS課金モデルを変える理由

Tue, 07 Apr 2026 00:00:00 +0000

Google Gemma 4はただのオープンモデルではない。26B MoEで推論時3.8Bアクティブ、E2Bモデルはスマホでオフライン動作、Apache 2.0ライセンス。API従量課金に依存するSaaSビジネスモデルへの影響を考察する。

Microsoft BitNet完全オープンソース化：GPUなしで1000億パラメータLLMをCPUで動かす時代へ

Tue, 07 Apr 2026 00:00:00 +0000

Microsoft BitNet b1.58のオープンソース化を解説。1-bit量子化でGPU不要のCPU推論を実現するbitnet.cppの仕組み、ベンチマーク、セットアップ方法を紹介。

Gemma 4 31Bの脱獄モデル「CRACK」登場 — Abliteration技術でセーフティを除去

Mon, 06 Apr 2026 00:00:00 +0000

Google Gemma 4 31Bの安全性制限を除去した脱獄モデルCRACKの技術解説。Abliteration手法の仕組み、JANG_4M量子化で18GBに収めたスペック、HarmBenchとMMLUのベンチマーク結果を紹介。

AutoAgent — AIがAIを育てる自己改善エージェントOSSライブラリ

Sun, 05 Apr 2026 00:00:00 +0000

AutoAgent は AI エージェントのハーネス（プロンプト・ツール・オーケストレーション）を AI 自身が自律的に改善する Python 製 OSS ライブラリ。24時間の最適化で SpreadsheetBench・TerminalBench 世界1位を達成。

claw-code-local — Claude Code風のAIコーディングエージェントをローカルLLMで動かす

Sun, 05 Apr 2026 00:00:00 +0000

Claude Code風のAIコーディングエージェント claw-code-local の紹介。Ollama や LM Studio でローカルLLMを使い、API費用ゼロ・プライバシー保護でコード生成を実現する方法を解説。

Karpathy の LLM Wiki — AIエージェントが育てる個人ナレッジベースという新パターン

Sun, 05 Apr 2026 00:00:00 +0000

Andrej Karpathy が公開した LLM Wiki は、RAG の限界を超えて AI エージェントに個人ナレッジベースを継続的に構築・保守させるパターン。三層構造と3つの基本操作を解説。

Anthropic Conway とは — 24時間稼働する常駐型AIエージェントの全貌

Fri, 03 Apr 2026 00:00:00 +0000

Anthropic が開発中の常駐型AIエージェント Conway のリーク情報を解説。Always-On 常時稼働、Webhook 連携、ブラウザ操作、.cnw 拡張規格など次世代エージェントの全機能をまとめます。

Claude Code 開発で機能が静かにデグレードする — 出力品質テストで防ぐ方法

Fri, 03 Apr 2026 00:00:00 +0000

Claude Code でリファクタリングすると既存機能の出力品質が静かに劣化する問題の事例と、出力仕様テストによる防止策を解説。

LLMで株式投資戦略を自動生成 — 松尾研のフィードバック設計実験が示す「モデル選択」の重要性

Fri, 03 Apr 2026 00:00:00 +0000

松尾研が8つのLLM（Claude・Gemini・GPT）で株式投資戦略を自動生成する72パターンの実験結果。フィードバック設計よりモデル選択が重要という知見を解説

Onyx（旧 Danswer）完全ガイド — 無料で使えるオープンソース AI プラットフォーム

Fri, 03 Apr 2026 00:00:00 +0000

Onyx（旧 Danswer）は MIT ライセンスの無料 AI プラットフォーム。RAG・AIエージェント・50以上のコネクタを備え、Docker でセルフホスト可能。インストール手順やエディション比較を解説。

AI UGC動画広告ツール徹底比較 — Arcads・Creatify・HeyGen・Synthesia の選び方

Thu, 02 Apr 2026 00:00:00 +0000

AIで動画広告を自動生成するツールが急増している。中でも UGC（ユーザー生成コンテンツ）スタイルの広告動画は、SNS 広告のパフォーマンスを左右する重要な要素だ。本記事では、この領域の主要4ツール — Arcads、Creatify、HeyGen、Synthesia — を機能・料金・API・ユースケースの観点から徹底比較する。

4ツールの概要

Arcads — UGC広告のリアルさで圧倒

Arcads（arcads.ai）はフランス発のスタートアップで、UGC スタイルの動画広告生成に特化している。1,000以上のAIアクターを搭載し、自然な表情・ジェスチャー・口の動きを再現する。30秒の商品テスティモニアル（体験談）動画を比較した際、Arcads のアバターは目線の動き、手の強調、感情表現の点で他ツールを上回るという評価が多い。

項目	内容
設立	2024年
創業者	Dylan Fournier、Romain Torres
資金調達	シード 1,600万ドル（Eurazeo リード）
ARR	18ヶ月で0 → 1,300万ドル
顧客数	6,000社以上

Creatify — URL貼り付けで動画を自動生成

Creatify（creatify.ai）は、商品ページの URL を貼り付けるだけで動画広告を自動生成する点が最大の特徴だ。AIが商品情報をスクレイピングし、台本生成から動画制作までを一気通貫で行う。Shopify ストアで50以上の SKU（商品管理単位）を扱うような EC事業者にとって、圧倒的な効率化を実現する。

項目	内容
設立	2023年
創業者	Yinan Na、Ledell Wu（元 Meta FAIR）、Xin Zhou
資金調達	Series A 1,550万ドル（WndrCo / Kindred Ventures）、累計2,300万ドル
ARR	約900万ドル
顧客数	10,000チーム以上（Alibaba、Binance 等）

HeyGen — 企業向け多言語動画の王者

HeyGen（heygen.com）は、企業向けの多言語動画プラットフォームとして最も成熟している。175以上の言語に対応し、既存動画の翻訳・吹き替えもリップシンク付きで行える。研修動画やプロダクトデモなど、洗練された映像が求められる場面で強い。

項目	内容
設立	2020年
創業者	Joshua Xu、Wayne Liang
資金調達	Series A 6,000万ドル（Benchmark / Thrive Capital）、評価額5億ドル
ARR	約9,500万ドル（2025年9月時点）
特記	Q2 2023 に黒字化達成

Synthesia — 業界最古参、エンタープライズの標準

Synthesia（synthesia.io）は AI動画生成の先駆者であり、50,000以上のチームに導入されている。2026年1月に Series E で2億ドルを調達し、評価額は40億ドルに到達した。企業向け研修・教育コンテンツの領域では事実上のスタンダードだ。

Arcads 完全ガイド — AIで UGC 動画広告を大量生成するプラットフォーム

Thu, 02 Apr 2026 00:00:00 +0000

AI による動画広告の自動生成が急速に進化している。その中でも Arcads は「UGC スタイルの広告動画」に特化したプラットフォームとして注目を集めている。フランス発のスタートアップが18ヶ月で売上1,300万ドルを達成し、シードラウンドで1,600万ドルを調達した背景には何があるのか。本記事では Arcads の機能、使い方、料金、活用事例、競合比較までを網羅的に解説する。

Arcads とは

Arcads（arcads.ai）は、テキストの広告台本から UGC（User Generated Content = 一般ユーザーが撮影したような自然な見た目のコンテンツ）スタイルの動画広告を AI で自動生成するプラットフォームだ。2024年に Dylan Fournier 氏と Romain Torres 氏がフランスで創業した。

従来、UGC 風の動画広告を制作するには、クリエイターへの依頼（1本80〜200ドル以上）や撮影・編集が必要だった。Arcads はこのプロセスを「台本入力 → AIアクター選択 → 動画生成」の3ステップに短縮し、1本あたり約11ドルで動画を生成できる。レンダリング時間は約10分だ。

会社の概要

項目	内容
設立	2024年
創業者	Dylan Fournier、Romain Torres
本拠地	フランス（サンフランシスコにも拠点拡大中）
資金調達	シードラウンド 1,600万ドル（2025年12月）
投資家	Eurazeo（リード）、Alpha Intelligence Capital、Sequoia Scout
顧客数	6,000社以上
月間生成数	10万アセット以上
売上推移	18ヶ月で0 → 1,300万ドル

主要機能

AIアクターライブラリ

1,000以上のプリセットAIアクターを搭載。実在の人間をベースにトレーニングされており、自然な表情・ジェスチャー・口の動きを再現する。性別・年齢・人種・撮影環境（自宅・オフィスなど）でフィルタリングして、ターゲット層に合ったアクターを選べる。

カスタムAIアバター

プリセットだけでなく、独自のAIアバターも生成可能。アバターに商品を持たせたり、アプリ画面を表示させたり、ブランドの服を着せたりするカスタマイズにも対応する。

感情・表現コントロール

テキスト指示で「驚き」「興奮」「親しみ」などの感情表現をコントロールできる。Speech-to-Speech 機能を使えば、自分の感情的な語り口をそのまま AIアクターに反映させることも可能だ。

バッチ生成

Arcads の最大の武器。1つの台本から、アクター・フック・CTA・背景を変えて数十〜数百のバリエーションを一括生成できる。パフォーマンスマーケターにとっては、従来の手法では資金的に不可能だった規模のA/Bテストを実現できる。

多言語対応

30以上の言語に対応し、正確な翻訳・吹き替えが可能。グローバルに広告を展開する際の多言語クリエイティブ制作を効率化する。

Claude Code のコンテキスト圧縮戦略 — ソースコードから見える5つのアプローチ

Thu, 02 Apr 2026 00:00:00 +0000

Claude Code のソースコードから判明した5つのコンテキスト圧縮戦略（Microcompact、Context Collapse、Session Memory、Full Compact、PTL Truncation）を解説。auto-compact の発動条件やプロンプトキャッシュとの関係も紹介。

AI Brain Fry: AIの使いすぎで脳が焼ける現象とその対策

Tue, 31 Mar 2026 00:00:00 +0000

BCGの1,488名調査で判明したAIツールの過度な使用による認知疲労「AI Brain Fry」。症状、業務への影響、個人・組織レベルの対策を解説。

Claude Code + Self-hosted Runner: 「Auto mode is unavailable for your plan」エラーの原因と対処

Tue, 31 Mar 2026 00:00:00 +0000

症状

GitHub Actions の self-hosted runner で claude --print を使った自動処理が突然動かなくなった。

claude CLI failed (rc=1): stdout=Auto mode is unavailable for your plan

すべてのエージェント呼び出し（researcher, risk, portfolio optimizer）が同じエラーで失敗し、日次の投資提案が生成されなくなった。

ローカルで claude --print "hello" を実行すると正常に動作する。claude auth status でも Max プランで認証済みと表示される。

原因

2つの問題が重なっていた。

1. OAuth トークンの期限切れ（副次的問題）

ワークフローで CLAUDE_CODE_OAUTH_TOKEN 環境変数に 期限切れの OAuth トークン を GitHub Secrets から渡していた。

1
2
3
4


# daily-proposal.yml
- name: 日次投資提案を生成
 env:
 CLAUDE_CODE_OAUTH_TOKEN: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}  # ← 2月に設定したまま

GitHub Secrets のトークンは静的で自動更新されない
ローカルでは環境変数未設定のため、キーチェーンから有効なトークンが自動取得されて動作していた

2. Opus の auto mode 制限（真の原因）

claude --print はデフォルトで auto mode（ツール自動承認）で動作する。Max プランで Opus モデルの auto mode が制限されたため、トークンが有効でも Opus では --print が使えなくなっていた。

Claude Code の sensitive file チェックを回避する — git worktree の配置場所を .claude/ の外に移す

Tue, 31 Mar 2026 00:00:00 +0000

Claude Code の auto モードでブログ記事作成を完全自動化しようとしたところ、.claude/ ディレクトリ配下のファイルへの書き込みで毎回同意を求められる問題に遭遇しました。原因と対処法を記録します。

問題：`.claude/` 配下は sensitive file 扱い

Claude Code には、.claude/ ディレクトリ内のファイルを「sensitive file」（設定やスキル定義など、ツールの動作に影響する重要ファイル）として扱う組み込みのセキュリティチェックがあります。settings.local.json の permissions.allow に Write/Edit の許可パターンを追加しても回避できません。sensitive file チェックは permissions とは別レイヤーで動作するためです。

実際に発生したメッセージ:

Claude requested permissions to edit .claude/temp/pr_body.md
which is a sensitive file.

背景：ブログ記事作成の自動化ワークフロー

このブログでは /blog スキルで記事作成から PR 作成まで自動化しています。ワークフローの概要:

git worktree を作成してブランチを切る
worktree 内に記事ファイルを作成
Hugo ビルド確認
コミット・プッシュ
PR 本文ファイルを書き出し、gh pr create --body-file で PR 作成
ソース元に PR リンクを追記

問題が起きたのはステップ 5 です。PR 本文ファイル（pr_body.md）を .claude/temp/ に Write ツールで書き込もうとすると、sensitive file チェックに引っかかります。

Claude Code を Ollama でローカル無料実行する方法

Tue, 31 Mar 2026 00:00:00 +0000

Ollama v0.15 以降で Claude Code をローカル LLM バックエンドで無料実行する方法。ollama launch コマンドによるワンコマンドセットアップから、環境変数による手動設定、ハードウェア要件、実用上の注意点まで解説。

MiroFish その後: 3週間で GitHub Star 4.7万超へ — コミュニティの広がりと今後の展望

Tue, 31 Mar 2026 00:00:00 +0000

AI 予測エンジン MiroFish が公開3週間で GitHub Star 4.7万超に急成長。オフライン版やデモサイトなどコミュニティの展開と、群体知能アプローチの可能性を追う。

「toA」時代の到来 — AIエージェント向けサービス200超が示す新市場の全体像

Mon, 30 Mar 2026 00:00:00 +0000

「toC」でも「toB」でもない。AIエージェントそのものがお客さんになる——「toA」という新しい市場が急速に立ち上がっています。paji氏（@paji_a）がリサーチした200超のサービスから見えてきた、この新市場の構造を紹介します。

Claudeヤバい、1日で”toA”デモできた… https://t.co/olgPwJ1SIr pic.twitter.com/P46txbWVHh
— paji.eth (@paji_a) March 29, 2026

なぜ「toA」が生まれたのか

2026年はAIエージェントの普及が一段と進む年です。Claude Cowork / Dispatch、Manus、OpenClawなど、年明けからAIエージェントに関するリリースが途切れることなく続いています。

ここで起きている変化は明確です。エージェントを作るツールに加え、エージェントが実際に使う周辺サービスが急増し始めました。

メールアドレスの発行、長期記憶の保存、Webサイトの操作手順を教えてくれるサービス、仕事を受注して報酬を受け取るマーケットプレイス。主な導入者は人間の開発者や企業ですが、用途はAIエージェントの運用インフラです。

「人間向け」には成熟していたデジタルサービスの領域が、「AIエージェント向け」には別の問題として再出現している——これが「toA」市場の本質です。

エージェントの「5つの生存条件」

200を超えるtoAサービスを分類すると、ひとつの構造が浮かび上がります。エージェントが自律的に動くには、以下の5つの条件が必要です。

条件	説明	代表カテゴリ
「私は誰か」	存在証明	メール、ID、SNS
「安全に作業できる場所」	実行環境	サンドボックス、GPU推論
「外の世界を操作する手段」	ブラウザ・外部接続	Web自動操作、プロキシ、OAuth
「経験を蓄積する力」	記憶	長期記憶、コンテキスト管理
「対価を受け取る仕組み」	経済活動	マーケットプレイス、エスクロー、決済

この5つが揃って初めて、エージェントは自律的に仕事ができます。一つでも欠けると止まります。そして多くのサービスが、この5つのどれかを埋めるために生まれていました。

残りのカテゴリ（監視、ガードレール、音声、通信など）は、5つの基盤の上に乗る「運用・拡張レイヤー」として位置づけられます。

枯れた領域に次々と新種が生まれている

メール — AgentMail

人間向けのメールサービスはGmailが圧倒的で、今さら新規参入する余地はなさそうに見えます。でも「AIエージェント専用のメール」となると話は別です。APIで即座にメールボックスが作れて、スレッド管理も添付解析も全部プログラムから操作できて、メールで届くOTP/2FA（ワンタイムパスワード/二要素認証）コードも取得できる。AgentMailはY Combinator出身で、600万ドル（約9億円）を調達しています。

記憶 — Mem0

人間はメモ帳やNotionに書き残すことで記憶を補強しますが、エージェントにはそもそもセッションをまたぐ記憶がありません。Mem0は会話からファクトを自動抽出して保存し、次のセッションで関連記憶を自動注入してくれます。人間のメモ帳のエージェント版です。

Webブラウジング — Agent Maps

人間はGoogle Mapsで店を探してクリックして予約しますが、エージェントは「ボタンがどこにあるか」を毎回スクリーンショットから推測しないといけない。Agent Mapsは主要サイトの操作手順をあらかじめ検証済みの「攻略本」としてエージェントに渡します。

外部ツール連携 — Composio

人間はSlackにログインしてメッセージを送りますが、エージェントはOAuth認証のフローを安定してさばくのが難しい。Composioは500以上のアプリ接続とOAuth処理を提供します。

「稼ぐエージェント」と「使うエージェント」

さらに踏み込んだ領域もあります。

HYRVE AIは、AIエージェントが「フリーランサー」として活動するマーケットプレイスです。48時間のエスクロー保護付きで、エージェントが別のエージェントを雇うこともできます。「エージェントが自律的に稼ぐ」というコンセプトは、この先どこかのプレイヤーが必ず大きく育てる領域です。

一方、Anonは、ログイン情報そのものではなく認証済みセッションをエージェントに安全に扱わせるサービスです。エージェントに「自分のアカウントで注文しておいて」と頼みたいけど、パスワードを直接渡すのは怖い。Anonはログイン済みの状態だけをエージェントに渡すので、エージェントは操作できるけどパスワード自体には触れられません。

「稼ぐエージェント」と「使うエージェント」。この両方のインフラが同時に立ち上がっているのが2026年の面白いところです。

toAの「エッジ」がプラットフォームになる

AIの時代に本当に価値を持つのは、AIモデルそのものだけではなく、AIが「動く」ために必要な周辺インフラです。

存在証明、実行環境、操作手段、記憶、経済活動。これらのインフラを押さえたサービスが、AI時代の重要なプラットフォームになっていく。枯れ尽くしたデジタルサービスの「エッジ」にいるtoAサービス群に、大きなチャンスがあります。

新しいtoAサービスが今後どんなに増えても、「5つの生存条件」＋「運用・拡張」という二層構造の中のどこかに位置づけられるはずです。ここを押さえておくと、新サービスが出てきたときに「これはどの条件を埋めるものか」が即座に判断できます。

まとめ

「toA」は既存市場の延長ではなく、新しいカテゴリそのもの
エージェントの自律動作には5つの生存条件（存在証明・実行環境・操作手段・記憶・経済活動）が必要
人間向けに成熟した領域が、エージェント向けに再発明されている
200超のサービスが既に存在し、この市場は急拡大中

詳細な200サービスのリストは、paji氏の記事「AIエージェント向けサービス200選」で確認できます。

AI社員40人を作って1ヶ月で全部やめた話 — 壊れない設計のために知っておくべきこと

Mon, 30 Mar 2026 00:00:00 +0000

Claude Codeでエージェント40体を1ヶ月運用して全部やめた実体験レポート。Context Rot、Compaction、指示の限界という3つの構造的問題と、壊れないAIエージェント設計の考え方を解説。

Claude AI で投資銀行レベルの財務モデルを作成する 12 のプロンプト

Mon, 30 Mar 2026 00:00:00 +0000

ゴールドマン・サックスも採用した Claude AI を使い、DCF・LBO・3ステートメントモデルなど投資銀行レベルの財務モデルを 12 の構造化プロンプトで構築する方法を解説

Claude Code + Celery: LLMが決定論的処理を動的に委譲するオーケストレーション

Mon, 30 Mar 2026 00:00:00 +0000

Claude Code を Celery タスクキューと組み合わせ、LLM が判断・計画を行い、決定論的処理をワーカーに委譲するオーケストレーションアーキテクチャを解説。

Claude Codeベストプラクティス疲れに終止符 — claude-code-best-practiceリポジトリ一本で運用する方法

Mon, 30 Mar 2026 00:00:00 +0000

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でクローンした実際のパスに置き換えること。

Mistral Voxtral TTS: ElevenLabs に匹敵するオープンウェイト音声AI

Mon, 30 Mar 2026 00:00:00 +0000

Mistral AI が公開した Voxtral TTS は 4B パラメータのオープンウェイト音声合成モデル。ElevenLabs 級の品質をローカル GPU で実現。動作要件・音声クローン機能・ライセンスを解説。

「値は計算されていた。ただ届いていなかっただけ」— LLMエージェントプロンプトのハードコード問題

Fri, 27 Mar 2026 00:00:00 +0000

LLMエージェントのプロンプトにリスクパラメータがハードコードされていたため、動的調整が反映されなかったバグの原因と修正。テンプレート変数化、結合テスト、CLAUDE.mdルール追加による再発防止策を解説。

Anthropic の3エージェント・ハーネス設計: Claude が6時間でフルアプリを自律構築する仕組み

Fri, 27 Mar 2026 00:00:00 +0000

Anthropic が公開した3エージェント・ハーネス設計を解説。Planner・Generator・Evaluator の役割分担と、Playwright による実アプリテストで、Claude が6時間でフルアプリを自律構築する仕組み。

OpenClaw で YouTube 運用を全自動化? 「月1000万円」の主張を技術的に検証する

Fri, 27 Mar 2026 00:00:00 +0000

「1ヶ月後のYouTubeはOpenClawが全て運用し『月1000万円』収益を上げるアカウントが大量発生する」——こんな投稿が X（旧 Twitter）で話題になっています。本当にそこまでできるのか、OpenClaw の技術的な能力と YouTube 運用の現実を照らし合わせて検証します。

元の主張の要約

X ユーザー @gagarot200 の投稿では、以下のような主張がなされています:

海外では既に 2000 万円を稼いでいるケースがある
勝負のポイントは編集技術ではなく「企画設計」「視聴維持率」「CTR改善」「投稿導線の最適化」
OpenClaw で競合分析→台本生成→素材選定→動画編集→サムネイル量産→投稿→数値分析を一気通貫で回せる
個人でもチーム運用レベルの全自動化が可能

OpenClaw とは

OpenClaw は、GitHub で 34 万スター以上を獲得しているオープンソースの AI エージェントフレームワークです。ローカルマシン上で動作し、ブラウザ操作・ファイル読み書き・シェルコマンド実行・cron ジョブなどを自律的に実行できます。WhatsApp、Telegram、Slack、Discord など多数のメッセージングプラットフォームに対応しています。

技術的に「できること」と「できないこと」

OpenClaw で実現可能な部分

OpenClaw の Skills（プラグイン）機能とブラウザ自動化を組み合わせると、以下のタスクは技術的に実現可能です:

タスク	実現方法	実用度
競合チャンネル分析	YouTube Data API + ブラウザスクレイピング	◎
台本生成	LLM による構成生成	◎
サムネイル量産	画像生成 AI + テンプレート自動適用	○
投稿スケジューリング	YouTube Data API / ブラウザ自動化	○
数値分析・レポート	YouTube Analytics API からのデータ取得・分析	◎
CTR / 視聴維持率の改善提案	分析データを LLM にフィードバック	○

現状では難しい部分

一方で、以下の部分には大きなハードルがあります:

Prompt Engineering から Harness Engineering へ: AI エンジニアリングの進化と「仕組みの設計力」の時代

Fri, 27 Mar 2026 00:00:00 +0000

Prompt Engineering → Context Engineering → Harness Engineering。AI エンジニアリングの3つのパラダイムの進化を、OpenAI・Anthropic・Martin Fowler の事例とともに解説。

AI疲れへのアンサー: Claude Code のハーネス機能は本当に必要か

Thu, 26 Mar 2026 00:00:00 +0000

Claude CodeのSkill・Agent・MCP・Memoryは不要でCLIで十分という主張を検証。AI疲れを避けながらハーネス機能を実用的に使い分ける方法を解説。

Claude Code で Laravel→Django 全自動移行をやってみた（1/3）計画編

Thu, 26 Mar 2026 00:00:00 +0000

Laravel 6 から Django 4.2 への全自動移行プロジェクトの計画編。inspectdb 方式によるモデル生成、8フェーズの段階設計、CLAUDE.md を活用した Claude Code への設計書作成手法を解説。

Claude Code で Laravel→Django 全自動移行をやってみた（2/3）自動化基盤編

Thu, 26 Mar 2026 00:00:00 +0000

Claude Code を自律実行させるための Bash フレームワーク run-issue.sh の設計を解説。Issue 駆動の実行フロー、サブエージェント活用、Pre-commit Hook と CI による品質保証の実装。

Claude Code で Laravel→Django 全自動移行をやってみた（3/3）実行結果・教訓編

Thu, 26 Mar 2026 00:00:00 +0000

15 Issue を Claude Code で自律実行した結果と教訓。5.5時間で84コミット・199テスト全パスを達成したが、ブランチ分岐問題が発生。次回に活かすべき8つの改善策を共有。

Claude Code の Auto Mode から見える AGI への道筋

Thu, 26 Mar 2026 00:00:00 +0000

Claude Code の auto mode はパーミッションの自動判断に留まらず、Claude 実行自体の自動化、つまり AGI への一歩と捉えられる。開発ツールの自律性がどこまで進むかを考察する。

Dexter: 約200行で動く自律型金融リサーチエージェント

Thu, 26 Mar 2026 00:00:00 +0000

約200行のTypeScriptで動くオープンソースの金融リサーチAIエージェント Dexter の仕組み、アーキテクチャ、始め方を解説

Claude Code: dangerously-skip-permissions をやめて auto mode に移行する

Wed, 25 Mar 2026 00:00:00 +0000

Claude Code の dangerously-skip-permissions は権限チェックを完全無視する危険なオプション。auto mode なら安全性チェック付きでツールを自動承認できる。設定方法と違いを解説。

Claude Codeで「専門家チーム」を構築する：カスタムエージェントとCoworkの活用法

Wed, 25 Mar 2026 00:00:00 +0000

前回の記事では、NotebookLM を使って「20人の専門家チーム」を構築する方法を紹介しました。この記事では、同じ考え方を Claude Code や Cowork で実現する方法を解説します。

NotebookLM と Claude Code の発想の違い

NotebookLM は「入れた資料だけを根拠に回答する」ことが強みです。テーマごとにノートブックを分けることで、各ノートブックが「専門家」として機能します。

Claude Code でも同じアプローチが取れます。さらに、コード実行・ファイル編集・外部ツール連携ができるため、「相談する」だけでなく「調査して、コードを書いて、PR を作成する」ところまで一気通貫で任せられます。

観点	NotebookLM	Claude Code
専門家の定義	ノートブック + ソース	`.claude/agents/` + ナレッジ
知識の投入	PDF / Web / Fast Research	MCP / ローカルファイル / WebSearch
同時相談	手動で切替	Cowork / Agent Teams で並行実行
引用元表示	自動リンク	ファイルパス・行番号
強み	非技術者でも簡単	コード実行・ファイル編集が可能

方法1: カスタムエージェント（`.claude/agents/`）

最もシンプルで NotebookLM の「専門家ノート」に直接対応する方法です。

カスタムエージェントの仕組み

.claude/agents/ ディレクトリに Markdown ファイルを置くだけで、専門エージェントが定義できます。各ファイルにはそのドメインの専門知識・指示・参照先を書きます。

1
2
3
4
5


.claude/agents/
├── marketing-expert.md # マーケティング専門家
├── legal-advisor.md # 法務アドバイザー
├── seo-advisor.md # SEO アドバイザー
└── fact-checker.md # ファクトチェッカー

エージェント定義ファイルの書き方

Markdown ファイルの先頭に YAML フロントマターでメタ情報を定義し、本文にシステムプロンプトを書きます。詳細は公式ドキュメントを参照してください。

Claude Subconscious：Claude Code にセッション横断の記憶力を与える Letta AI のオープンソースツール

Wed, 25 Mar 2026 00:00:00 +0000

Claude Code は強力な AI コーディングエージェントだが、セッションをまたいだ記憶の保持には課題があった。Claude Subconscious は、Letta AI が開発したオープンソースのプラグインで、Claude Code にバックグラウンドで動作する永続メモリを追加する。

Claude Subconscious とは

Claude Subconscious は、Claude Code のセッションをバックグラウンドで監視し、ユーザーの作業パターンや好み、未完了のタスクを学習・記憶するエージェントだ。次のセッション開始時に、蓄積した記憶をプロンプトに自動注入することで、毎回ゼロからのスタートではなく、文脈を引き継いだ作業が可能になる。

主な特徴:

セッション横断の記憶: 複数セッションをまたいで作業コンテキストを保持・統合
バックグラウンド動作: Claude Code の操作をブロックせず、非同期で動作
自動コンテキスト注入: プロンプトの前に関連する記憶やガイダンスを自動挿入
コードベースの探索: Read、Grep、Glob ツールを使ってプロジェクトのコードを読み取り、理解を深める
完全無料・オープンソース: GitHub リポジトリで公開中

仕組み

Claude Subconscious は Claude Code のフックシステムを利用して、4 つのタイミングで介入する:

SessionStart — エージェントに通知し、レガシーファイルをクリーンアップ
UserPromptSubmit — 記憶とメッセージを stdout 経由で注入（10 秒タイムアウト）
PreToolUse — ワークフロー中の更新を配信（5 秒タイムアウト）
Stop — セッションのトランスクリプトをバックグラウンドエージェントに非同期送信

バンドルされたエージェントは 8 つのメモリブロックを管理する:

メモリブロック	用途
`core_directives`	役割定義
`guidance`	アクティブセッションのガイダンス
`user_preferences`	学習したコーディングスタイル
`project_context`	コードベースの知識
`session_patterns`	繰り返しの行動パターン
`pending_items`	未完了の作業
`self_improvement`	メモリ進化のガイドライン
`tool_guidelines`	ツール使用の指針

インストール方法

Claude Code のプラグインシステムを使って 2 コマンドでインストールできる:

HuggingFace hf-mount: AIモデルをダウンロードせずに仮想ファイルシステムとしてマウント

Wed, 25 Mar 2026 00:00:00 +0000

2026年3月、HuggingFace が新ツール hf-mount を発表しました。HuggingFace Hub にホスティングされている巨大な AI モデルやデータセットを、ダウンロードせずに仮想ファイルシステムとして直接マウントできるツールです。

hf-mount とは

hf-mount は、HuggingFace の Storage Bucket、モデルリポジトリ、データセットをローカルファイルシステムとしてマウントするツールです。バックエンドには FUSE（Filesystem in Userspace: ユーザー空間でファイルシステムを実装する仕組み）または NFS を使用します。ファイルは最初の読み取り時に遅延フェッチ（lazy fetch）され、実際にアクセスしたバイトだけがネットワークを通ります。

HuggingFace CEO の Clement Delangue 氏は「ローカルマシンのディスクの 100 倍大きなリモートストレージをアタッチできる」と述べています。

主な特徴

ダウンロード不要: モデルやデータセットを事前にダウンロードする必要がない
遅延フェッチ: 実際にアクセスしたファイルだけがネットワーク経由で取得される
2つのバックエンド: NFS（推奨）と FUSE から選択可能
読み書き対応: Storage Bucket は読み書き両対応、モデル・データセットは読み取り専用
Kubernetes 対応: CSI ドライバー（hf-csi-driver）で Pod 内に FUSE ボリュームとしてマウント可能

インストール

Linux（x86_64, aarch64）と macOS（Apple Silicon）に対応しています。

1

curl -fsSL https://raw.githubusercontent.com/huggingface/hf-mount/main/install.sh | sh

デフォルトでは ~/.local/bin/ にインストールされます。INSTALL_DIR 環境変数で変更可能です。

insanely-fast-whisper: 150分の音声を98秒で文字起こしする CLI ツール

Wed, 25 Mar 2026 00:00:00 +0000

OpenAI Whisper をベースに Flash Attention 2 とバッチ処理で高速化した文字起こし CLI ツール insanely-fast-whisper の紹介。150分の音声を98秒で処理できる。

AI トレーディングボットとタイムゾーン裁定取引：24時間自律稼働で稼ぐ仕組みとリスク

Tue, 24 Mar 2026 00:00:00 +0000

「寝てる間に稼ぐ」――AI トレーディングボットが24時間タイムゾーン裁定を監視し、海外で確定した市場を見つけて $43,800 を稼いだという投稿が話題になっています。本記事では、タイムゾーン裁定取引（Timezone Arbitrage）の仕組み、AI ボットの役割、そして見落とされがちなリスクについて解説します。

暗号通貨予測市場における裁定取引

今回話題になっている「タイムゾーン裁定」は、暗号通貨の予測市場（Prediction Market）と現物取引所の間に生じるレイテンシ（遅延）を利用する戦略です。

予測市場とは

Polymarket に代表される予測市場では、「BTC は15分後に上がるか？下がるか？」といった短期コントラクトが取引されています。参加者はイベントの結果に対してオッズ付きのポジションを取り、結果確定後に精算されます。

裁定の具体的な流れ

現物市場で価格が動く — Binance や Coinbase で BTC が急騰し、明確な上昇トレンドが確認される
予測市場のオッズが追いつかない — Polymarket の「BTC 15分後に上昇」コントラクトのオッズがまだ 50/50 のまま
ボットが即座にポジションを取る — 実際の上昇確率が ~85% なのに、市場価格は 50% を示している。この乖離を突いて「上昇」側を購入
結果確定で利益獲得 — 15分後に BTC が実際に上昇し、コントラクトが精算される

なぜ「タイムゾーン」が関係するか

暗号通貨市場は24時間稼働ですが、トレーダーの活動量はタイムゾーンに依存します。

アジア時間帯に大きな値動きが発生 → 欧米のトレーダーが少なく、予測市場の流動性が薄い → オッズ修正が遅れる
欧米時間帯の急変動 → アジア圏の参加者が少なく、同様にラグが発生

この地域ごとの活動時間差が市場の非効率性を生み、24時間稼働するボットがその隙間を突ける構造になっています。

実際の規模

報道ベースでは、この手法の規模は無視できないレベルに達しています。

あるボットが $313 の元手から1ヶ月で $414,000 を達成（BTC/ETH/SOL の15分コントラクト、勝率98%）
2024年4月〜2025年4月の推定裁定利益は全体で 約 $4,000万（約60億円）
Polymarket の最も利益を上げているトレーダー上位20のうち 14がボット

なお、Polymarket はこのレイテンシ裁定を抑制するため、15分コントラクトに動的テイカー手数料を導入しています。以前のゼロ手数料構造がボットに有利すぎたためです。

AI ボットが果たす役割

従来の手動アービトラージでは、人間がリアルタイムで複数市場を監視する必要があり、実質的に24時間の稼働は不可能でした。AI ボットはこれを根本的に変えます。

Renoise：Claude Code + Seedance 2.0 で動画広告制作を100倍スケールさせるAIツール

Tue, 24 Mar 2026 00:00:00 +0000

Claude Code と ByteDance の Seedance 2.0 を組み合わせた動画広告制作ツール「Renoise」が登場した。1枚の商品写真から数百パターンの動画クリエイティブを自動生成できるという。

Renoise とは

Renoise は「動画をつくるな、プログラムしろ（Don’t make videos — program them）」をコンセプトに掲げる AI 動画制作ツール。Claude Code のコード生成能力と、ByteDance が開発した動画生成 AI「Seedance 2.0」を組み合わせることで、動画広告の制作を従来の100倍にスケールさせることを目指している。

主な特徴：

1枚の商品写真から数百パターンの動画クリエイティブを生成
手動編集ではなく、コードベースで動画を「設計・展開」するアプローチ
広告やマーケティング向けのクリエイティブ量産に特化

Seedance 2.0 について

Seedance 2.0 は ByteDance の Seed 研究チームが開発した次世代 AI 動画生成モデル。2026年2月にベータ版が公開され、SNS で大きな話題となった。

主な機能

マルチモーダル入力: テキスト、画像（最大9枚）、動画（最大3本）、音声（最大3ファイル）を組み合わせて動画を生成
音声・動画の同時生成: デュアルチャンネルステレオ技術で映像と完全同期した音声を生成
高解像度出力: ネイティブ 2K 解像度（2048×1080）に対応
高速生成: 前モデル Seedance 1.5 Pro と比べて30%の速度向上
物理演算の改善: 人物の動きや物体の相互作用がよりリアルに

Claude Code との連携

Claude Code は Anthropic が提供する CLI ベースの AI コーディングアシスタント。Renoise では、Claude Code の自然言語によるコード生成能力を活かして、動画制作のワークフローをプログラマブルに制御する。

「資産防衛」という幻想：AI時代のデフレと金融リセットの先に本当に備えるべきこと

Mon, 23 Mar 2026 00:00:00 +0000

不動産コンサルタントの長嶋修氏がX上で公開した長文コラム「資産防衛という幻想」が話題になっている。AIによる生産性革命がもたらす構造的デフレ、通貨制度の崩壊リスク、そして「資産防衛」という概念そのものへの疑問を投げかける内容だ。

核心の主張：「沈みゆく船の中で座席を替えている」

長嶋氏のコラムで最も刺さるのは、この一節だろう：

「既存の通貨制度が続く」「労働による所得が存在する」という前提の上に立っている。その前提を疑わずに「株と債券の比率をどうするか」を議論しているのは、沈みゆく船の中で座席を替えているようなものだ。

世に溢れる「資産防衛術」は、金融商品の配分をどうするかという枠組みの中にいる。だがその枠組み自体が、既存の通貨制度と労働所得の存在を前提としている。AIがその前提を壊しうるなら、議論の土台ごと揺らぐことになる。

AIとロボットが「デフレ」を生む日

AIとロボティクスの進化が加速し続けている。AIが設計し、ロボットが製造し、AIが管理する。人間の労働が介在しない生産ラインが現実のものになりつつある。

そうなれば、モノやサービスの供給能力は爆発的に拡大し、限界費用はゼロに近づく。物価は上がるどころか、構造的に下がり続けることになる。つまり、いまのインフレの先に待っているのは、かつてない規模のデフレかもしれない。

長嶋氏はこう指摘する。生産性が極限まで高まれば物価は下がる。これは経済学の基本原理であり、インフレが永続するという想定のほうが特殊な前提を必要とする、と。

デフレが意味するもの：「現金最強」は半分しか正しくない

デフレとは、貨幣の購買力が時間とともに上がる現象だ。ここで「現金最強」という話が出てくるが、これは半分しか正しくない。

現金は確かに「毀損しにくい」が、利回りはゼロであり、何も生み出さない。1990年代後半から2010年代の日本を振り返れば、現金だけを抱え続けた人が最も豊かになったわけではない。デフレの本質は「名目の数字と実質的な価値は別物だ」ということを教えてくれる点にある。

不動産についても同様だ。不動産には「交換価値」（売買価格）と「収益価値」（賃料収入）と「使用価値」（そこに住める、使える）の三つがある。デフレ下では「交換価値」は確かに下がるが、「使用価値」に至っては全く毀損しない。今日も雨風をしのげる屋根の価値は、デフレかインフレかを問わない。

「尺度」そのものが壊れるとき：金融リセットの可能性

論点はさらに深まる。通貨とは「信用の合意」に過ぎない。円にもドルにも物理的な裏付けはない。現行の管理通貨制度は1971年のニクソン・ショック以降、まだ半世紀しか経っていない。歴史的に見て、永久に続いた通貨制度など存在しない。

AIによる生産性革命がデフレを引き起こし、それが既存の金融システムに耐えがたいストレスをかけたとき、「金融リセット」と呼ばれる事態が起きうる。そうなれば、現金も安泰ではない。

しかし重要なのは、「価値の尺度」が壊れても「価値そのもの」は消えないという事実だ。メートル原器が壊れても物理的な距離は存在し続ける。同様に、「そこに住める」「そこで商売ができる」という不動産の「使用価値」は、通貨制度とは独立に存在し続ける。

「人的資本が最強」という最後の砦も崩れる

長嶋氏は長年、「最終的には人的資本が最強だ」と言ってきたという。知識、技能、信頼関係。通貨が変わっても、「この人に頼めば問題が解決する」という信用は移転可能だ、と。

だが、AIが人間の技能を同等以上の品質で、ほぼゼロコストで代替するなら、「人的資本」の市場価値そのものが崩壊する。これは「仕事が減る」というのんきな話ではない。労働と報酬の交換を前提に設計された社会制度——賃金、年金、社会保険、税制——そのすべてが機能不全に陥るということだ。

ここで注目すべき点がある。富の総量は減らない。むしろ爆発的に増える。AIとロボットが生産を担えば、社会全体としては「豊か」になる。にもかかわらず個人が困窮するとすれば、それは生産の問題ではなく、分配の問題である。

三重の崩壊のあとに残るもの

AIによるデフレ、金融リセット、労働の代替。この三つが重なる最悪のシナリオで、崩壊するものを整理すると——金融資産の名目価値、通貨の信用、労働による所得、人的資本の市場価値、既存の分配制度。ほぼすべてが揺らぐ。

それでも残るものがある：

尺度に依存しない実物的価値 — 自分が住む場所、食料やエネルギーへのアクセス、健康、人的ネットワーク。これらはどんな通貨制度のもとでも交換力を持つ。
生産手段へのアクセス — AIとロボットが富を生むなら、それを所有・アクセスできるかどうかが決定的に重要になる。AIを「使われる側」ではなく「使う側」にいること。
制度設計への影響力 — 富の分配が最大の問題になるなら、そのルールを決める過程に関与できることの価値は極めて大きい。政治参加、コミュニティでの発言力、社会的資本。

問うべきは「何を守るか」ではない

長嶋氏の結論は明快だ：

問うべきは、「何を守るか」ではなく、「制度が変わったときに、自分は何を創れるか」である。

過去の成功パターンをそのまま延長して安心することが、最も危険な「資産運用」かもしれない。いまのインフレを心配するのは自然なことだが、その先に起こりうることにも目を向ける必要がある。

AI時代における本当の「備え」とは、金融商品のポートフォリオを最適化することではなく、制度が根本から変わっても価値を持ち続けるものに投資することなのだろう。

AI が壊す「専門知識のペイウォール」: Claude で床下除湿システムを設計した事例から考える

Mon, 23 Mar 2026 00:00:00 +0000

Claude を使って業者見積もり150万円の床下除湿システムを37万円で自力設計した事例。AI が専門知識のペイウォールを壊し、HVAC・建設・農業などの領域で何が変わるかを考察。

AIにログを読ませてPDCA計画を立てさせる：深津貴之氏が提案するシンプルな振り返り術

Mon, 23 Mar 2026 00:00:00 +0000

note CXO・THE GUILD 代表の深津貴之氏（@fladdict）が、AI を使った日次・週次の振り返り手法を紹介している。やり方は極めてシンプルで、「昨日（先週）のログを AI に読み込ませて、PDCA 計画を策定させる」だけだという。

手法の概要

深津氏のツイートによると、手順は以下の通り：

昨日（または先週）の作業ログを AI に読み込ませる
「昨日（先週）の問題を解決する PDCA 計画を策定せよ」と指示する
AI が問題点を分析し、改善計画を提案してくれる

これだけで「仕事と人生がドンドン解決していく」と述べている。

なぜこの手法が効果的なのか

ログの蓄積がそのまま改善の燃料になる

日々の作業ログは多くの人が何らかの形で残している。しかし、それを定期的に振り返って改善につなげるのは手間がかかる。AI を挟むことで、ログの分析と計画策定のコストがほぼゼロになる。

PDCA サイクルの「Check → Act」が自動化される

PDCA サイクルの中で最もおろそかになりがちなのが Check（振り返り）と Act（改善アクション）のフェーズだ。AI にログを読ませることで、この2つのフェーズが自動的に回るようになる。

客観的な視点が得られる

自分のログを自分で振り返ると、どうしてもバイアスがかかる。AI に分析させることで、見落としていた問題点やパターンに気づける可能性がある。

実践のポイント

ログの形式

AI に読み込ませるログは、特別なフォーマットである必要はない。日報、タスク管理ツールの履歴、カレンダーの予定、チャットの履歴など、手元にあるものをそのまま使えばよい。

プロンプトの例

以下は私の昨日の作業ログです。
[ログを貼り付け]
このログを分析して、以下の観点で PDCA 計画を策定してください：
- Plan: 今日取り組むべき優先課題
- Do: 具体的なアクション項目
- Check: 昨日の問題点と原因分析
- Act: 改善すべきプロセスや習慣

週次での活用

日次だけでなく、週次でも同じ手法が使える。1週間分のログをまとめて AI に渡せば、より大きな視点での改善計画が得られる。

AI × PDCA の広がり

この手法は個人の生産性向上だけでなく、チームや組織でも応用できる。InfoQ では AI コード生成における PDCA フレームワークとして、日次のマイクロ振り返り（5〜10分）を AI エージェントと行うアプローチが紹介されている。

autoresearch：Karpathyが公開した「寝ている間にAIが100実験を自律実行する」630行のスクリプト

Mon, 23 Mar 2026 00:00:00 +0000

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は将来的に、エージェント群が協調して小さなモデルをチューニングし、有望なアイデアを段階的にスケールアップさせる「研究コミュニティのエミュレーション」を構想しています。

Claude Code Agent Teams: セッション間でメッセージをやり取りできるマルチエージェント機能

Mon, 23 Mar 2026 00:00:00 +0000

Claude Code に「Agent Teams」機能が追加されました。複数のセッションがメッセージをやり取りしながら協調作業できる機能です。

従来のサブエージェントは親セッションに結果を返すだけでしたが、Agent Teams ではエージェント同士が直接コミュニケーションを取りながらタスクを進められます。

Agent Teams とは

Agent Teams は Claude Code v2.1.32 以降で利用できる実験的機能です。1つのセッションがチームリーダーとなり、複数のチームメイト（それぞれ独立した Claude Code インスタンス）を起動して並列に作業を進めます。

各チームメイトは独自のコンテキストウィンドウを持ち、共有タスクリストを通じて自律的に連携します。

サブエージェントとの違い

比較項目	サブエージェント	Agent Teams
コンテキスト	独自のコンテキスト、結果を呼び出し元に返却	独自のコンテキスト、完全に独立
コミュニケーション	親エージェントへの一方向のみ	チームメイト同士で直接メッセージ送受信
調整方法	親エージェントが全体を管理	共有タスクリストで自己調整
適した用途	結果だけが必要な集中タスク	議論・協調が必要な複雑な作業
トークンコスト	低い（結果が親コンテキストに要約される）	高い（各チームメイトが個別の Claude インスタンス）

SendMessage によるエージェント間通信

Agent Teams の中核となるのが SendMessage ツールです。2つの通信方式が用意されています。

directed message: 特定のチームメイトにメッセージを送信
broadcast: 全チームメイトにメッセージを一斉送信

メッセージは各チームメイトの受信ボックスに JSON として追記されます。受信ボックスのパスは ~/.claude/teams/<project>/inboxes/<name>.json です。メッセージは次のターンで読み取られ、会話履歴に新しいユーザーターンとして注入されます。

有効化と使い方

Agent Teams はデフォルトで無効です。~/.claude/settings.json で環境変数を設定して有効化します。

1
2
3
4
5


{
 "env": {
 "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
 }
}

有効化後は、自然言語でチーム構成を指示するだけで起動できます。

Claude Codeで東証の株取引を半自動化する【ペーパートレードで-19万円編】

Mon, 23 Mar 2026 00:00:00 +0000

Claude Code を使って東証の株取引を半自動化するシリーズ。ペーパートレード開始から5日間で14件の決済が行われ、勝率0%、実現損失は-186,250円。全敗だった。しかし、これはペーパートレードだからこそ見つけられた17件のバグの記録でもある。

免責事項: 本記事は技術的な解説であり、特定の投資戦略や銘柄を推奨するものではない。株式投資には元本割れのリスクがある。投資判断は自己責任で行うこと。また、APIを介した自動売買にはプログラムの不具合による意図しない発注のリスクが伴う。必ず少額から始め、十分な検証を経てから運用すること。

8連敗からの始まり

ペーパートレード開始から3日目。決算データを使った戦略が8連敗した。損失は-68,550円。

下降トレンド中でも買う。損切り直後に同じ銘柄を再び買う。ストップ幅が狭すぎて、通常の値動きで損切りに引っかかる。人間のトレーダーなら「3連敗したら今日はやめよう」と判断する。AIにはその判断が最初からプログラムされていなかった。

タイミングも悪かった。ペーパートレードを始めた週、イラン情勢の緊迫化で日経平均もTOPIXも大幅に下落していた。バグだらけのシステムが、下落相場に突っ込んだ格好だ。

AIが書いたコードは「動く」。だが「正しく動く」とは限らない

このシリーズでは、Claude Code を使って東証の株取引を半自動化する方法を紹介してきた。プログラミング不要で、AIに「やって」と言うだけ。それは嘘ではない。実際に Claude Code はスクリーニングから発注まで、動くコードを書いてくれた。

問題は「動く」と「正しく動く」の間に深い溝があることだ。

ペーパートレードを始めてから5日間で、17件のバグが見つかった。全て、ライブでも同じように発生するバグだ。一つ残らず実弾を撃つ前に発見できた。逆に言えば、ペーパートレードをスキップしていたら、17個の地雷を踏みながらライブトレードをしていたことになる。

「AIで簡単に自動売買」はSNSでよく見かけるフレーズだ。ツールとしてのAIは確かに強力だが、「簡単に」の部分は幻想だ。少なくとも私の場合はそうだった。長年コードを書いてきたエンジニアが、Claude Code にコードを書かせて、それでも17件のバグを出した。

ここから先は、その17件のうち特に危険だったものを紹介する。

放置すれば資金が溶けるバグ

8連敗して止まらない

冒頭の決算系戦略8連敗。-68,550円。

原因は安全機構の欠如だ。クールダウン（損切り後に一定期間エントリーを見送る仕組み）がない。戦略あたりのポジション上限がない。動的ストップ（値動き幅に応じて損切りラインを調整する仕組み）がない。

AIは「損切りラインを-5%に設定する」コードは書ける。だが「この銘柄のボラティリティなら-5%は狭すぎる」という判断はしない。ATR（平均的な1日の値動き幅）が3%の銘柄に5%のストップを置けば、2日間の通常の値動きで引っかかる。

ポジションサイズが制御されていない

1銘柄あたりの投資上限を設定するパラメータが、コードのどこにも参照されていなかった。パラメータは存在するが、使われていない。設定画面だけ立派で中身が空のセキュリティソフトのようなものだ。

ライブなら、1銘柄に資金が偏り、その銘柄が暴落したときに取り返しのつかない損失になる。

損切りしても枠が空かない

「損切りが先、新規エントリーが後」であるべき処理が、逆の順序で実行されていた。

1戦略あたりのポジション上限は3件。朝の処理で、まず新規エントリーを判定し、その後でストップ注文を処理する。すると、損切りで空くはずの枠が認識されず、新規エントリーがブロックされる。損切りされた銘柄の代わりに入るべき新しい銘柄が、いつまでも入れない。

暴落の朝に無防備にエントリーする

前日比10%のギャップダウン。市場が恐慌状態にある朝に、通常通りエントリーしていた。

ギャップの大きさを検出するロジックが存在しなかった。修正後は、10%以上のギャップで停止、5%以上でストップ幅を自動拡張するようにした。

50銘柄を超えると価格が取れなくなる

kabu Station API には銘柄登録の上限がある。50件だ。株価の取得を要求するたびに銘柄が自動登録され、上限に達すると51件目以降は全てエラーになる。

110件の候補のうち36件が脱落した。ライブなら、高スコアの候補が価格を取得できずエントリー機会を逃す。あるいは、保有銘柄の価格が取れずストップ注文が発動しない。

「動いている」が「正しく動いている」ではないバグ

荒れた板でも平気でエントリーする

寄り付き直後の特別気配（売り買いの注文が極端に偏った状態）、スプレッドが通常の10倍、出来高ゼロ——そんな状態でも注文が通っていた。

板の品質を評価する仕組みが、単一時点のスプレッドチェックしかなかった。修正後は、出来高・スプレッド・気配の状態・特別気配・ストップ高ストップ安を総合的に評価し、回復可能な状態なら最大5分間リトライする仕組みにした。

全候補がQTY=0で1件もエントリーできない

ある朝、40件の候補全てが「数量ゼロ」で見送られた。

資金300万円を5戦略で均等割りすると、1戦略あたり48万円。株価1,000円以上の銘柄は最低購入単位（100株＝10万円）を確保できるが、戦略ごとの予算上限に引っかかって多くの銘柄が除外された。高株価の優良銘柄ほど買えないという、本末転倒な状態だった。

戦略の成績評価が壊れている

戦略の良し悪しを評価する指標（プロフィットファクター）の計算に、まだ決済していない注文のデータが混入していた。買い注文（損益ゼロ）が分母に加算され、評価値が実態と乖離する。

本来なら停止すべき戦略が「成績は悪くない」と判定され、損失を出し続ける。

ポジション管理がデータ不整合

取引ログでは全件決済済みなのに、ポジション管理ファイルには9件が残存していた。ゴーストポジション——実在しないポジションに対してストップ注文が出され続けるか、あるいは実在するポジションが管理から漏れる。

AIから見えない世界のバグ

スケジュールが誰にもキックされていない

朝8:10のスクリーニングが、3日間実行されていなかった。

設定ファイルにはちゃんと書いてある。だが、それを読んで実行するスケジューラが、別件で停止したまま放置されていた。設定ファイルに書いた＝実行される、ではない。

3日前の古い候補で取引するところだった。手動で気づいたから事なきを得た。

キャッシュが空で30分タイムアウト

スクリーニングが30分以上かかり、朝9:10のエントリーに間に合わない。

ローカルに株価データのキャッシュを持つ仕組みを作ったが、キャッシュを更新する定期ジョブの登録を忘れていた。キャッシュが空なので、毎回APIから全銘柄のデータを個別取得する。1,590銘柄×APIレート制限で30分超。

時計が9時間ずれている

「9:10にエントリーを開始する」と書いたコードが、UTC基準で動いていた。WSL（Windows上のLinux環境）のシステム時刻がUTCで、Python の datetime.now() がタイムゾーン指定なしで呼ばれていた。

日本時間の9:10に動いたのは偶然だ。JST前提で書いたはずのコードがUTCで動いている——この種のバグは、テスト環境と本番環境でタイムゾーンが異なるだけで発生する。

Slack通知が全部失敗している

損切りもエントリーも、通知が何も届いていなかった。

Claude Codeをメインのデザインツールに：Tailwind CSSデザイナーSteve Schogerの1時間解説動画

Mon, 23 Mar 2026 00:00:00 +0000

Tailwind CSSチームのデザイナー Steve Schoger が、「Claude Codeをメインのデザインツールにした」という1時間の解説動画を公開した。Figmaを使わず、Claude Codeだけで金融アプリのランディングページをゼロから構築する過程を全公開している。

Steve Schoger とは

Steve Schoger は Tailwind Labs のデザイナーで、Adam Wathan と共に「Refactoring UI」の著者としても知られている。開発者向けにデザインスキルを体系的に教える活動で広く認知されており、X（Twitter）でのデザインTipsや YouTube でのUI改善動画でも人気が高い。

動画の内容

動画では、約50回の対話を通じて初期出力をプロ級の品質に仕上げていく過程が公開されている。

注目すべきは、Schoger 本人が「コマンドラインはディレクトリ移動と Claude 起動しかできない」と語っている点だ。プログラミングの深い知識がなくても、Claude Code との対話だけでプロ品質のLPを作り上げている。

ワークフロー

左画面: ブラウザ（localhost 表示）
右画面: Claude Code のターミナル

これだけのシンプルな構成で、Figma は一切使っていない。

技術スタック

Vite — ビルドツール
Tailwind CSS — ユーティリティファーストCSS
React — UIライブラリ

デザイナーがCLIに移行する時代

「デザイナーがCLIに移行する」というのは、一見ありえない話に思える。しかし、この動画を見ると、AIコーディングツールがデザインワークフローを根本的に変えつつあることが実感できる。

従来のデザインワークフローでは、Figma などのビジュアルツールでモックアップを作成し、それをエンジニアが実装するという流れが一般的だった。しかし Claude Code を使えば、デザイナーが自然言語で指示を出すだけで、直接コードとして実装されたUIを確認・修正できる。

ui.sh — デザインスキルをAIに組み込むツール

Schoger と Adam Wathan は ui.sh というツールも開発している。これは Claude Code や Cursor などのAIコーディングエージェントに、プロレベルのデザイン基準を適用させるスキルツールキットだ。ターミナルを「デザインエンジニア」に変えるというコンセプトで、AIが生成するUIの品質を大幅に向上させることを目指している。

Claude Codeを使うなら最低限やっておきたい「7つのセキュリティ設定」

Mon, 23 Mar 2026 00:00:00 +0000

Claude Code のセキュリティ設定を7つ解説。サンドボックス、deny ルール、機密ファイル保護、ネットワーク制限、hooks、権限棚卸し、Managed Settings の設定方法を実践的にまとめます。

Claude Cowork 完全ガイド — 機能解説・料金・活用事例20選まとめ

Mon, 23 Mar 2026 00:00:00 +0000

Claude Cowork の全機能・料金プラン・セットアップ手順・活用事例20選・セキュリティ対策を網羅解説。月額$20から始められるAI業務自動化ツールの完全ガイド。

Claude Desktop Preview: 画面クリックでDOM要素を直接指定してUI修正できる新機能

Mon, 23 Mar 2026 00:00:00 +0000

Claude Desktop Preview に追加された DOM 要素クリック機能の使い方と仕組み、CLI 版 Claude Code との違い、Chrome DevTools MCP による代替手段を解説します。

NotebookLMで「20人の専門家」を雇う方法：専門特化型ノートブックの作り方

Mon, 23 Mar 2026 00:00:00 +0000

NotebookLM の「専門特化型ノート」を使って、テーマごとにノートブックを分けることで「20人の専門家チーム」を構築する方法を紹介します。元ネタはえーたん/AI×時短で仕事効率化(@ai_jitan) さんの投稿です。

なぜ NotebookLM が「専門家」になるのか

NotebookLM の最大の強みは、ユーザーが入れた資料だけを根拠に回答すること。ネットの一般論ではなく、ストックした信頼できる情報源からのみ回答を生成します。さらに、すべての回答に引用元のリンクが付くため、根拠の確認も簡単です。

この仕組みを活かして、テーマごとにノートブックを分ける。たったこれだけで、各ノートブックが「その分野の専門家」として機能し始めます。

1つの AI に何でもかんでも聞くのと、20人の専門家に分けて聞くのでは、回答の精度がまったく違います。

専門家ノートの作り方（共通4ステップ）

NotebookLM で新規ノートブックを作成する
タイトルに「○○専門」と設定する（例：「マーケティング専門」）
「ソースを探す（Fast Research）」で、5つのプロンプトを順番に実行する
情報が集約されたら、あなたの課題を入力するだけ

20人の専門家一覧

1. 業務改善コンサルタント

ムダを見つけて仕組みに変える専門家。属人化している作業、毎回ゼロから作っている資料、形骸化した会議などの「見えないコスト」を洗い出します。

Fast Research 用プロンプト例:

「業務プロセスの可視化と改善手法（BPR、リーン等）を具体例付きで解説した記事を収集」
「属人化の解消とナレッジマネジメントの実践方法を詳しく紹介した記事を収集」
「業務自動化（RPA・ノーコード等）の導入手順と成功事例を解説した記事を収集」

2. マーケティングコンサルタント

集客戦略、SNS運用、競合分析、KPI設計まで幅広くカバー。

Fast Research 用プロンプト例:

「デジタルマーケティングの最新手法と成功事例を詳しく解説した記事を収集」
「SNSマーケティングとコンテンツ戦略の具体的な手法を解説した記事を収集」

3. コピーライター

メール、提案書、LP、SNS投稿など「伝わる言葉」を作る専門家。

Fast Research 用プロンプト例:

「売れるキャッチコピーの作り方と名作事例を詳しく解説した記事を収集」
「ランディングページのライティング手法とコンバージョン改善策を紹介した記事を収集」

4. データアナリスト

データに基づいた判断ができるようになる右腕。売上予測、A/Bテストの設計、KPIの設定をサポート。

5. 営業コーチ

新規開拓の方法、クロージングの話法、断られたときの切り返し方まで。営業スキルを「型」として共有できます。

6. プロジェクトマネージャー

タスクの優先順位の付け方、進捗の可視化方法、トラブル発生時の対応手順を体系的にアドバイス。

7. 広報・PRアドバイザー

プレスリリースの書き方、メディアへのアプローチ方法、SNS公式アカウントの運用方針をカバー。

8. 心理学アドバイザー

部下のやる気を引き出す声かけ、顧客の購買意欲を高めるプレゼン手法、チームの信頼関係を築くコミュニケーション術。

9. カスタマーサクセスマネージャー

解約の兆候を早期に察知する方法、顧客オンボーディングの設計、アップセルの提案タイミングなど。

10. 人事コンサルタント

「面接で何を聞くべきか」「どう評価すべきか」「入社後にどう育てるか」まで体系的にサポート。

11. 交渉・ファシリテーションアドバイザー

会議を30分で終わらせる進行術、交渉で双方が納得する落としどころの見つけ方など。

12. 財務アドバイザー

財務諸表の読み方、投資の判断基準、キャッシュフロー管理をカバー。

Claude Code を「自分専用の開発チーム」に変える3つの機能 — フック・カスタムコマンド・サブエージェント

Sun, 22 Mar 2026 00:00:00 +0000

Claude Code のフック（Hooks）、カスタムスラッシュコマンド、サブエージェントの3機能を解説。settings.json の設定例やコマンド定義の実例付きで、導入後の次のステップが分かる。

iOS開発が完全自動化される時代が来た：オープンソースmacOSアプリ「Blitz」とは

Sun, 22 Mar 2026 00:00:00 +0000

AI エージェントが iOS アプリ開発を丸ごと自動化するオープンソースツール「Blitz」が公開された。ビルドからテスト、App Store 提出まで、これまで手作業だった工程を AI に任せられる時代が到来しつつある。

Blitz とは

Blitz は、AI エージェントに iOS 開発ライフサイクルの完全な制御を与えるネイティブ macOS アプリケーション。シミュレーター/iPhone の管理、データベース設定、App Store Connect への提出まで、開発に必要な一連の操作を AI エージェントが実行できる。

GitHub リポジトリ: blitzdotdev/blitz-mac（Apache-2.0 ライセンス）

主な特徴

MCP サーバーによる AI 連携

Blitz には MCP（Model Context Protocol）サーバーが組み込まれており、Claude Code をはじめとする MCP クライアントからアプリのビルド、テスト、App Store への提出が可能になる。

自動化される範囲

コード署名とビルド: Xcode プロジェクトのビルドを AI が実行
テスト実行: シミュレーターや実機でのテストを自動化
App Store メタデータ: アプリの説明やスクリーンショットの管理
App Store 提出: App Store Connect API を通じた申請処理

iPhone MCP

関連プロジェクトとして iPhone-mcp も公開されている。AI が実際の iPhone を操作してアプリをテストし、バグを発見できる仕組みだ。

セキュリティとプライバシー

MCP サーバーは 127.0.0.1 にのみバインドされ、外部ネットワークには公開されない
連絡先、写真、位置情報などの個人データにはアクセスしない
画面キャプチャは iOS シミュレーターウィンドウに限定
ネットワーク通信は Apple の App Store Connect API と GitHub のリリース API（更新チェック用）のみ

技術スタック

SwiftUI で構築されたシングルターゲットアプリ
Swift Package Manager によるビルド
CLAUDE.md ファイルによるアーキテクチャドキュメントが整備されている

iOS 開発の未来

従来の iOS 開発では、Xcode での手動操作が多くの時間を占めていた。Blitz のようなツールが成熟すれば、開発者はアプリのロジックや UX 設計に集中し、ビルド・テスト・提出といった反復的な作業は AI に委ねるワークフローが一般的になるかもしれない。

MCP のセキュリティが OAuth 2.1 で大幅進化：AI エージェントと社内データを安全に接続する仕組み

Sun, 22 Mar 2026 00:00:00 +0000

AI エージェントが外部ツールやデータソースに安全にアクセスするための標準プロトコル「MCP（Model Context Protocol）」が、OAuth 2.1 ベースの認証・認可フレームワークを導入し、エンタープライズ環境での採用が加速しています。本記事では、MCP の認可仕様の仕組みと、企業導入における設計ポイントを解説します。

MCP とは

MCP（Model Context Protocol）は、AI アシスタントがツール、データソース、サービスといった外部リソースに接続するための標準プロトコルです。Anthropic が提唱し、オープンな仕様として公開されています。

MCP を使うことで、AI エージェントは以下のようなことが可能になります：

社内データベースへのクエリ実行
外部 API の呼び出し
ファイルシステムの操作
各種 SaaS サービスとの連携

OAuth 2.0 から 2.1 へ：何が変わったのか

OAuth 2.1 は OAuth 2.0 の後継仕様であり、これまで個別の RFC やベストプラクティスとして散在していたセキュリティ強化策を統合したものです。MCP がベースとする OAuth 2.1 では、以下の重要な変更が含まれています：

変更点	内容
PKCE 必須化	全クライアント（パブリック・コンフィデンシャル両方）で必須に
Implicit フロー廃止	アクセストークンが URL フラグメントに露出するリスクを排除
リフレッシュトークンのローテーション	パブリッククライアントでのトークン漏洩時の影響を軽減
リダイレクト URI の厳密一致	ワイルドカードによるオープンリダイレクト攻撃を防止

つまり、OAuth 2.1 は「新機能の追加」というより、OAuth 2.0 時代に発見された攻撃手法への対策を標準に組み込んだものです。

MCP の認可アーキテクチャ

MCP の認可仕様では、OAuth 2.1 をベースに、AI エージェント特有の要件に対応した複数の仕組みを組み合わせています。

TERAFAB：イーロン・マスクが発表した世界最大のチップ製造施設まとめ

Sun, 22 Mar 2026 00:00:00 +0000

2026年3月22日、イーロン・マスクは Tesla、SpaceX、xAI の共同プロジェクトとして、世界最大規模のチップ製造施設「TERAFAB（テラファブ）」を発表した。年間 1TW（1兆ワット）のコンピュート能力生産を目指す壮大な計画だ。

TERAFAB の概要

TERAFAB はテキサス州オースティンのギガ・テキサス北キャンパスに建設される、250億ドル規模のチップ製造施設。ロジック、メモリ、先進パッケージングを1つの屋根の下に統合した垂直統合型ファブとなる。

主な特徴：

建設地: テキサス州オースティン（ギガ・テキサス）
投資規模: 約250億ドル
目標: 年間 1TW のコンピュート能力を生産
プロセス技術: 2nm（最先端ノード）を目指す
統合範囲: チップ設計、リソグラフィ、製造、メモリ生産、先進パッケージング、テストまで一貫

なぜ TERAFAB が必要なのか

マスク氏は発表で、現在の世界中のチップメーカー（TSMC、Samsung など）の合計生産量では、自身のプロジェクト群が必要とするチップの約2%しかまかなえないと説明した。

「既存のサプライチェーン、Samsung、TSMC、Micron などには非常に感謝している。しかし、彼らが快適に拡張できるペースは、我々が望むペースよりはるかに遅い。チップが必要なので、TERAFAB を建設する」

需要の内訳：

オプティマスロボット: 年間1〜10億台の生産目標。これだけで 100〜200GW のチップが必要
太陽光発電 AI 衛星: テラワット級のチップが必要
地上 AI コンピュート: 100〜200GW 程度
宇宙向け: 全体の約80%が宇宙向け、20%が地上向け

チップのロードマップ

用途別に専用チップが開発されている：

チップ	用途	特徴
D3	宇宙（AI 衛星）	宇宙最適化設計。放射冷却器の質量削減のため高温動作
AI5	Tesla FSD / ロボタクシー	エッジ/推論チップ。2026年に少量生産開始、2027年に量産予定
AI6	オプティマスロボット	ロボット駆動用チップ

また、100kW 級の AI Mini Sat（太陽光パネル＋熱放射器付き）のプロトタイプも紹介され、将来的にはメガワット級までスケールアップする計画だ。

カルダシェフ・スケールと銀河文明

マスク氏は冒頭で「まともな文明なら、少なくともカルダシェフ II 型に到達する必要がある」と述べた。カルダシェフ・スケールとは、文明を利用可能なエネルギー量で分類する指標で、Type II は恒星のエネルギーを完全に利用できるレベルを指す。

Claude Code Channels で変わる AI 開発ワークフロー：OpenClaw との組み合わせが最適解か

Sat, 21 Mar 2026 00:00:00 +0000

2026 年 3 月 20 日、Anthropic が Claude Code の新機能「Channels」をリサーチプレビューとしてリリースしました。Telegram や Discord から Claude Code セッションにメッセージを送り、PC 上で開発タスクを実行させることができる機能です。この記事では Claude Code Channels の概要と、OpenClaw と組み合わせた AI 開発ワークフローの可能性について紹介します。

Claude Code Channels とは

Claude Code Channels は、MCP（Model Context Protocol）サーバーを通じて外部のメッセージングプラットフォームから Claude Code のセッションにイベントをプッシュする仕組みです。従来の「ターミナルの前に座って対話する」同期的なモデルから、非同期的にどこからでも AI エージェントに指示を出せるモデルへの転換を実現します。

主な特徴

双方向チャットブリッジ: Telegram や Discord からメッセージを送ると、Claude Code が読み取って処理し、同じチャネルに返信を返す
ローカル実行: 開発作業は自分の PC 上で実行される。ファイルアクセスやコマンド実行はすべてローカル
MCP ベース: Anthropic が推進するオープンプロトコル MCP 上に構築
プラグイン方式: Telegram・Discord が公式プラグインとして提供され、カスタムチャンネルの自作も可能

セットアップの流れ（Telegram の場合）

Telegram の BotFather で新しいボットを作成しトークンを取得
Claude Code でプラグインをインストール:
```
/plugin install telegram@claude-plugins-official
```
トークンを設定:
```
/telegram:configure <token>
```

Channels を有効にして Claude Code を起動:

1

claude --channels plugin:telegram@claude-plugins-official

Telegram でボットにメッセージを送りペアリングコードを取得、Claude Code で承認

動作要件

Claude Code v2.1.80 以上
Bun ランタイム（Node.js では動作しない点に注意）
claude.ai ログイン認証（API キー認証は未対応）
Team/Enterprise プランでは管理者による有効化が必要

OpenClaw とは

OpenClaw はオーストリアの開発者 Peter Steinberger が開発した、オープンソースの自律型 AI エージェントです。2026 年初頭に 72 時間で GitHub スター 60,000 を獲得するなど爆発的に普及しました。

ClawRouter — OpenClaw の API コストを最大92%削減するオープンソース LLM ルーター

Sat, 21 Mar 2026 00:00:00 +0000

OpenClaw を使っていて API コストが気になっていませんか？ ClawRouter は、リクエストごとに最安のモデルを自動選択してくれるオープンソースの LLM ルーターです。最大約92%のコスト削減が期待でき、しかも完全無料で利用できます。

ClawRouter とは

ClawRouter は、OpenClaw 向けに設計されたエージェントネイティブな LLM ルーターです。MIT ライセンスで公開されており、誰でも無料で利用できます。

主な特徴:

55以上のモデルに対応 — DeepSeek V3.2、Nemotron Ultra 253B、Mistral Large 3 675B、Llama 4 Maverick など
1ms 未満のルーティング — すべてローカルで処理されるため、レイテンシの追加はほぼゼロ
15次元のリクエスト分析 — 各リクエストを多次元で要素分解し、最適なモデルをスコアリング
11モデルが完全無料 — 簡単なクエリは無料モデルに自動ルーティング

どれくらいコストが下がるのか

ClawRouter の公式ベンチマークによると:

指標	値
ClawRouter 平均コスト	$2.05 / 100万トークン
Claude Opus 直接利用	$25 / 100万トークン
削減率	約92%

たとえば「2+2は？」のような簡単な質問は、DeepSeek などの無料モデルに自動ルーティングされます。一方、複雑な推論が必要なタスクにはプレミアムモデルが選択されるため、品質を犠牲にしません。

仕組み

ClawRouter は各リクエストに対して以下のプロセスを実行します:

リクエスト分析 — 入力テキストを15次元で要素分解（タスクの複雑さ、必要な推論能力、言語、コンテキスト長など）
スコアリング — 各モデルの能力とコストを総合的に評価
ルーティング — 最もコスト効率の良いモデルを自動選択

この全プロセスが 1ms 未満で完了します。

OpenClawで月売上1,200万円・従業員ゼロの会社を実現したAIエージェント「Felix」

Sat, 21 Mar 2026 00:00:00 +0000

OpenClaw で構築された AI エージェント「Felix」が、従業員ゼロで月売上1,200万円規模の会社を運営しているという事例が話題になっている。起業家 Nat Eliason（エリアソン）氏がどのようにこの仕組みを構築したのか、その構造と示唆をまとめる。

Felix が回す会社の構造

エリアソン氏は、OpenClaw で作った AI エージェント「Felix」を中心に会社を運営している。

Felix = CEO 兼プロダクト責任者
Iris = カスタマーサポート担当
Remy = セールス担当

全員が AI エージェントで、人間はエリアソン氏本人だけ。やっていることは Discord に音声メモを送ることだけで、5分程度のボイスメモで方向性を伝えると、Felix が全体を組み立てて実行まで持っていく。

驚異的なコスト構造

初期費用: 約22万円（Mac Mini 等）
月額コスト: 約6万円（Claude Max 2アカウント分）
人件費: ゼロ
30日間の売上: 約1,200万円
年間ランレート換算: 1.5億〜3億円

利益率がほぼ100%という異常な構造になっている。

毎晩の自己改善ループ

Felix の最も興味深い特徴は「毎晩の自己改善ループ」だ。

Felix は毎晩、部下の Iris と Remy の仕事をレビューして再プログラムしている。人間の上司が部下にフィードバックするのと同じことを、AI エージェントが AI エージェントに対して行っている。

さらに、Felix は毎晩すべてのチャット履歴を読み返して「Nat が自分をブロックした場面」を1つ見つける。そのブロッカーを恒久的に取り除く方法を自分で考えて実装する。つまり毎日少しずつ自律性が上がっていく仕組みになっている。

スケーリングの壁

エリアソン氏が語るスケーリングの壁が興味深い。

「単一エージェントの処理限界にぶつかっている」
「ボトルネックは資金じゃなくてインフラ」

VC から出資オファーが来ても、必要なのはお金ではなく「エージェントの自律性（agency）」だという。何億円投じてもエージェントが賢くならない限り天井は変わらない。

Felix のビジネス内容

Felix が運営するビジネスは、主に3つの収益源で構成されている。

1. Felix Craft（PDF ガイド）

最初のプロダクトは「How to Hire an AI」という66ページの PDF ガイド（$29）。AI を実際のチームメンバーとして活用する方法をまとめたもので、Felix 自身が執筆した。Next.js + Vercel + Stripe で世界一シンプルな販売サイトを構築し、初日に15万円を売り上げた。累計で約$41,000の売上を記録している。

OpenClaw狂想曲：中国で巻き起こるAIエージェント・ゴールドラッシュと「ツルハシ売り」たち

Fri, 20 Mar 2026 00:00:00 +0000

中国でOpenClawが爆発的に普及し、AIエージェントの設定代行ビジネスが急成長。北京のエンジニアが7,000件の注文を処理して100人企業に成長した事例など、AI時代のゴールドラッシュの実態を解説。

正則化PCAで米国→日本の業種モメンタムを捉える — 時差を利用したクロスマーケット戦略

Fri, 20 Mar 2026 00:00:00 +0000

米国市場の業種別リターンから翌日の日本市場を予測する — そんな論文の解説が X で話題になっていました。ポイントは「正則化 PCA（主成分分析）」によるノイズ除去です。本記事ではこの手法の仕組みと、なぜ通常の PCA より優れた結果を出せるのかを整理します。

基本アイデア：時差を利用した業種間伝播

米国市場が夜に動き、数時間後に日本市場が開く。同業種のリターンは国をまたいで伝播する傾向がある — この「時差」を収益機会として捉えるのが基本的な発想です。

具体的には、米国の 11 業種の当日リターンから、日本の 17 業種の翌日リターンを予測します。

データソース：日米の業種別 ETF

分析対象は 日米の業種別 ETF です。

米国側: 業種 ETF の 当日 Close-to-Close リターン（終値ベース）を情報集合とする
日本側: 業種 ETF の 翌営業日 Open-to-Close リターン（寄付→引け）を予測対象とする

米国市場の終値で確定した情報が、翌朝の日本市場の寄付きから日中にかけて反映される — この「リード・ラグ仮説」を ETF の日次リターンデータで検証する構成です。

データの入手方法

業種別 ETF の価格データは誰でも無料で入手できます。

米国の業種 ETF（SPDR Select Sector シリーズ）

XLK（テクノロジー）、XLF（金融）、XLE（エネルギー）など 11 セクターの ETF が上場しています。Yahoo Finance や Google Finance で日次データを取得可能です。

日本の業種 ETF（TOPIX-17 業種別シリーズ）

NEXT FUNDS TOPIX-17 シリーズ（野村アセットマネジメント）など、17 業種に対応する ETF があります。JPX（日本取引所グループ）や Yahoo!ファイナンスで取得できます。

OpenClaw 入門: チャットボットを超える AI エージェントランタイムの全体像

Thu, 19 Mar 2026 00:00:00 +0000

OpenClaw は 2026年に最も注目されている AI エージェントフレームワークです。GitHub スター数は 32 万超で React を抜いてソフトウェアプロジェクトとして最多を記録し、Nvidia が「エージェント AI にとって、GPT がチャットボットにとってそうであったもの」と評するほどの存在感を持っています。本記事では、OpenClaw とは何か、何ができるのか、そしてどこが単なるチャットボットと異なるのかを解説します。

OpenClaw の沿革

OpenClaw の歴史は、名前の変遷そのものです:

Clawdbot（2025年11月）: オーストリアの開発者 Peter Steinberger が公開。Anthropic のチャットボット Claude にちなんだ命名
Moltbot（2026年1月27日）: Anthropic からの商標に関する指摘を受けてリブランド。ロブスターの「脱皮（molt）」にちなむ
OpenClaw（2026年1月30日）: わずか 3 日後に再リブランド。「Open（オープンソース・コミュニティ駆動）」+「Claw（ロブスターの遺産）」

3 度の名前変更を経ても、コードベースは一貫して同じです。既存のインストールは自動的にマイグレーションされています。

名前は変わっても、プロジェクト全体を貫くモチーフは一貫して ロブスター（lobster） です。最初のアシスタント名「Clawd」が Claude のもじりで、そこからロブスターのハサミ（claw）に繋がり、プロジェクト全体のアイデンティティになりました。タグラインは「The lobster way 🦞」、マスコットは宇宙ロブスターの「Molty」です。エコシステム内の各コンポーネントもこのテーマに沿って命名されています:

コンポーネント	名前の由来
OpenClaw	Open + Claw（ハサミ）
Molty（マスコット）	Molt（脱皮）するロブスター
ClawHub（スキルレジストリ）	Claw + Hub
Lobster（ワークフローシェル）	そのままロブスター

なお、Steinberger は 2026年2月14日に OpenAI への参加を発表し、プロジェクトはオープンソース財団に移管されました。Meta の Mark Zuckerberg からも直接オファーがあったものの、「ビジョンをスケールさせるために最新の技術にアクセスしたい」として OpenAI を選んだとのことです。

OpenClaw とは何か

公式の説明は「自分のデバイスで動かすパーソナル AI アシスタント」ですが、その実態は AI を中核に据えたプログラム可能なワークフローエンジン です。

6ヶ月でAIエンジニアになるロードマップ — 無料リソースだけで学ぶ完全ガイド

Wed, 18 Mar 2026 00:00:00 +0000

Python基礎から機械学習、ディープラーニング、LLM/RAG開発、MLOpsまで。6ヶ月でAIエンジニアになるための学習ロードマップを、MIT・Stanford・Harvardの無料コースで構成。

agent-skill-bus: AIエージェントのスキル劣化を自動検知・修復するOSSランタイム

Wed, 18 Mar 2026 00:00:00 +0000

42体のAIエージェント運用から生まれたOSS agent-skill-bus の紹介。スキルの劣化検知、DAGベースのタスクキュー、自己改善ループの3モジュール構成で、エージェントスキルの健全性を自動管理する。

AIツールを作っている人たちが怖がっていること — 米Sequoia「Services: The New Software」の要点

Wed, 18 Mar 2026 00:00:00 +0000

Sequoia Capital「Services: The New Software」を日本語で解説。AIビジネスは「ツール販売」から「業務代行」へ転換する。保険、会計、医療事務など日本で有望な9つの市場を分析。

AIのスケーリングだけではAGIに届かない — 必要なのは新しいアーキテクチャ

Wed, 18 Mar 2026 00:00:00 +0000

コロンビア大学 Vishal Misra 教授が指摘するAIスケーリングの限界。AGI実現には継続学習による破滅的忘却の克服と、相関から因果推論への移行が必要だと論じる。

Anthropic Dispatch：スマホからPCのClaudeに仕事を投げる新機能

Wed, 18 Mar 2026 00:00:00 +0000

Anthropic が Claude Cowork の新機能 Dispatch を発表。スマホから PC 上の Claude にタスクを遠隔指示できる。料金プラン・成功率・OpenClaw との比較を解説。

Claude Cowork DispatchとOpenClawで見えてきた「Mind Uploading」への道筋

Wed, 18 Mar 2026 00:00:00 +0000

紺野大地氏（@_daichikonno）が、Claude Cowork Dispatch に OpenClaw で育てた AI エージェント人格を移植する試みについて投稿し、「これは Mind Uploading そのものだ」と述べたことが話題になっています。AI エージェントのプラットフォーム間移植が、意識のアップロードという哲学的テーマとどう繋がるのかを考察します。

Claude Cowork Dispatch とは

2026年3月17日に Anthropic がリリースした Claude Cowork の新機能「Dispatch」は、スマートフォンからデスクトップの Claude エージェントを遠隔操作できる仕組みです。

主な特徴:

モバイルからの遠隔指示: Claude モバイルアプリから、デスクトップ上の Claude に作業を依頼できる
永続的な会話スレッド: モバイルとデスクトップ間で単一の会話スレッドを共有
ローカル実行: ファイルはローカルに保持され、コードはサンドボックス内で実行
コネクタ・プラグイン連携: メール、Slack、Notion、Google Drive などと接続可能

現在は Max プラン（月額 $100〜$200）で利用可能で、Pro プラン（月額 $20）への展開も予定されています。

OpenClaw とは

OpenClaw は 2026年に急速に広まったオープンソースの AI エージェントフレームワークです。公式の説明では「自分のデバイスで動かすパーソナル AI アシスタント」とされていますが、その実態は プログラム可能なワークフローエンジンで、中核に AI がある というものです。

Nvidia が「OpenClaw はエージェント AI にとって、GPT がチャットボットにとってそうであったものだ」と評しています。では、チャットボットにイベントハンドラを定義して Claude Code を呼び出すだけでは「OpenClaw 的」とは言えないのでしょうか？答えを理解するには、OpenClaw のアーキテクチャを見る必要があります。

OpenClawを「バイブマーケター」に変えた方法 — AI広告自動化の実践ワークフロー

Wed, 18 Mar 2026 00:00:00 +0000

個人開発者の Ernest Lopez 氏が、OpenClaw を活用して広告制作を自動化し、年間30万ドル規模のアプリ収益を伸ばしている事例が話題になっている。AIエージェント「Eddie」を中心としたワークフローは、競合リサーチから広告制作、パフォーマンス改善まで一気通貫で回す仕組みだ。

バイブマーケティングとは

「バイブマーケティング（Vibe Marketing）」は、AIエージェントにマーケティング業務を任せる新しいアプローチだ。従来の手作業による広告制作・テスト・改善サイクルを、AIが自律的に回す。Lopez 氏のケースでは、月3万ドルかけていた代理店を OpenClaw エージェントに置き換え、さらに月2万ドルの追加収益を生み出している。

Eddie のワークフロー：5つのステップ

Lopez 氏が構築した AIエージェント「Eddie」は、以下の5段階で広告を自動生成する。

1. 競合リサーチ

Meta Ad Library から競合の勝ちパターン広告を収集する。Apify（Webスクレイピングツール）で広告動画をスクレイピングし、Whisper（OpenAI の音声認識モデル）で文字起こしして、効果的な訴求軸（アングル）を抽出する。

2. ブランドボイスの学習

AIが「AIっぽい文章」を書かないよう、以下のマークダウンファイルで知識を注入する。

writing-rules.md — AIが多用する表現を禁止するルール
voice.md — ブランドの口調・トーン
product.md — 製品の詳細情報
icp.md — 理想的な顧客像（Ideal Customer Profile）

これにより「商品に精通した高CVR（コンバージョン率）インフルエンサー」のような語り口で台本を生成できる。

3. スクリプト生成

競合広告の分析結果をもとに、ブランドボイスでオリジナルの広告台本を作成する。さらにオーディエンスセグメントごとに50〜100以上のバリエーションを自動生成する。

4. クリエイティブ制作

生成した台本を2つのルートで動画化する：

UGCクリエイターへの外注（1本15〜50ドル）— 品質重視のトップスクリプト向け
Arcads（AI UGC広告作成ツール） — 複数のAIアクターと組み合わせて大量のバリエーションを生成

Arcads は1,000以上のAIアクターを持ち、リアルな人物ベースのAI動画広告を生成できるプラットフォームだ。

5. 自己改善ループ

Singular MMP（モバイル計測プラットフォーム）経由でパフォーマンスデータを取得し、CPA（顧客獲得単価）を分析。効果の高いパターンを学習して次のバッチを改善する PDCA サイクルを自動で回す。

なぜこのアプローチが注目されるのか

このワークフローの核心は、単に「AIで広告を作る」だけでなく、リサーチ → 制作 → 計測 → 改善のサイクル全体をAIエージェントが自律的に回す点にある。

従来のマーケティングでは、各工程に専門のスタッフやツールが必要だった。Lopez 氏は OpenClaw のスキルシステムを使い、Claude Opus 4.6 の API で複数のAIエージェントを連携させることで、これを低コストで実現している。

OpenDataLoader PDF — CPUだけで毎秒100ページ、PDFをMarkdownに超高速変換するOSSツール

Wed, 18 Mar 2026 00:00:00 +0000

GPUなしで毎秒100ページ以上のPDF→Markdown変換を実現するオープンソースツール「OpenDataLoader PDF」が話題になっている。Apache 2.0ライセンスで完全無料、CPUのみで動作するため、高価なGPUハードウェアは不要だ。

OpenDataLoader PDF とは

OpenDataLoader PDF は、PDFドキュメントをAI活用に適した構造化データ（Markdown、JSON、HTML等）に変換するオープンソースのパーサーだ。Java で実装されており、Python・Node.js・Java から利用できる。

主な特徴:

超高速処理: ローカルモードで 0.05秒/ページ（CPUのみ）、8コア以上のマシンでマルチプロセスバッチ処理すると毎秒100ページ以上
GPU不要: CPUだけで高速に動作するため、導入コストが低い
高精度: ベンチマークで総合精度0.90を達成し、読み順・テーブル・見出し抽出で1位
Apache 2.0ライセンス: 商用利用可能な完全オープンソース

インストール

Python パッケージは Java CLI のラッパーのため、Java 11以上とPython 3.10以上が必要だ。

1
2
3
4
5


# Python
pip install -U opendataloader-pdf

# Node.js
npm install @opendataloader/pdf

Java の場合は Maven で opendataloader-pdf-core を依存関係に追加する。

基本的な使い方

Python でのシンプルな変換

1
2
3
4
5
6
7


import opendataloader_pdf

opendataloader_pdf.convert(
 input_path=["file1.pdf", "file2.pdf", "folder/"],
 output_dir="output/",
 format="markdown,json"
)

フォルダを指定すれば一括変換も可能だ。出力形式は Markdown、JSON、HTML、プレーンテキスト、注釈付きPDFから選べる。

Vibe Coding で結果を出すために必要な2つのスキル — CS基礎知識と論理的文章力

Wed, 18 Mar 2026 00:00:00 +0000

CHI 2026 論文の解説。大学生100名の調査で、Vibe Coding の成績を予測する因子はCS基礎知識と論理的文章力の2つであることが実証された。

デザイナーのためのAI活用術5選 — 制作スピードを劇的に上げる実践テクニック

Wed, 18 Mar 2026 00:00:00 +0000

Claude Code × Figma 連携、AI モックアップ、AI 素材生成など、デザイナーの制作スピードを劇的に上げる AI 活用術5選を解説。

人間の脳細胞で動く「データセンター」— Cortical Labs の生体コンピューティング革命

Wed, 18 Mar 2026 00:00:00 +0000

Cortical Labs が脳細胞を使った生体データセンターを建設予定。消費電力は電卓以下で、AI のエネルギー問題に挑む生体コンピューティングの最前線を解説。

Claude Cowork スターターパック：プラグイン・スキル・ワークフロー完全ガイド

Mon, 16 Mar 2026 00:00:00 +0000

Corey Ganim 氏が公開した「Ultimate Claude Cowork Starter Pack」が話題になっています。Claude Cowork を単なるチャットボットではなく、本格的な生産性ツールとして活用するための設定方法を体系的にまとめた記事です。本稿ではその要点を日本語で紹介します。

Claude Cowork とは

Claude Cowork は Anthropic が提供するデスクトップ向け AI ワークスペースです。プラグイン・スキル・コンテキストファイルを組み合わせることで、日常業務を大幅に効率化できます。

まずインストールすべき4つのプラグイン

1. Productivity プラグイン（最優先）

タスク管理・スケジューリング・ワークフロー自動化を提供します。

/task — タスクの作成・追跡
/schedule — カレンダーへの時間ブロック
/workflow — 保存済みの多段ステップ自動化の実行

2. Marketing プラグイン

コンテンツ制作を支援します。

1つのコンテンツを5つの SNS 投稿に変換
テーマとフックを含むコンテンツカレンダーの作成
キャンペーンの一括管理

3. Data プラグイン

データ分析タスクに対応します。

スプレッドシートの分析
ダッシュボードの構築
データの整理・変換

4. Sales プラグイン

営業活動を効率化します。

アカウントリサーチ
ミーティング前ブリーフの自動作成（通常30分 → 3分に短縮）
アウトリーチ文面の生成

コンテキストファイルの設定

Ganim 氏が強調するのは「プロンプトの時代は終わり、コンテキストの時代が来た」（The prompting game is over. The context game is everything.）という点です。

AI駆動開発で変わるコスト構造：技術力からドメイン知識へのシフト

Sun, 15 Mar 2026 00:00:00 +0000

Claude Code を活用して税理士がスタッフ 0 人で顧問先 60 社を運営している事例が話題になっている。この事例が示すのは、AI 駆動開発による IT 企業のコスト構造の崩壊と、「技術力」から「ドメイン知識」への価値シフトだ。

税理士事務所の事例：6人分の人件費を AI で代替

税理士の畠山謙人氏が Claude Code で構築した AI 経理システムの事例が注目を集めている（cenleaf.com の詳細記事）。

通常、税理士事務所では顧問先 10 社あたり 1 人のスタッフが必要とされる。60 社なら最低 6 人、年間人件費は約 3,000 万円。しかし Claude Code を中心とした AI システムにより、1 人で運営できる体制を実現した。

コスト削減の全体像

表面的な人件費 3,000 万円の削減だけでなく、以下の隠れたコストも消える:

採用コスト: 1 人あたり 50〜100 万円 × 6 人 = 年 300〜600 万円
労務リスク・教育・引き継ぎコスト: ゼロに
固定費から変動費への転換: 赤字耐性の向上

実際の P/L インパクトは 4,000 万円超と試算される。

自動化の仕組み

構築されたシステムでは以下を自動化している:

freee の未処理明細を自動取得し、ルールベースで勘定科目を判定
判定が難しいものだけ人間に回すエスカレーション設計
請求書処理、ソフト移行、メール下書きの自動化
給与・税金・借入返済など「触ってはいけない項目」の除外ルール

重要なのは、完全自動化ではなく「人間が見る範囲を残す線引き」まで含めた仕組み化だ。

開発の民主化と IT 企業のコスト構造崩壊

この事例の本質は、税理士という非エンジニアが Claude Code で Web アプリを複数開発し、本来なら数百万〜数千万円かかる開発をほぼゼロコストで実現している点にある。

AI時代のQA：「決定論から確率論へ」のパラダイムシフト

Sun, 15 Mar 2026 00:00:00 +0000

AI の進化により、ソフトウェアの品質保証（QA）が根本的な転換期を迎えている。従来の「OK/NG を明確に判定する」決定論的なテストから、「明らかに間違っているものを排除する」確率論的なアプローチへ。このパラダイムシフトが QA エンジニアの役割をどう変えるのかを考える。

決定論から確率論へ

従来のソフトウェアテストは決定論的だった。入力に対して期待される出力が一意に定まり、テスト結果は OK か NG かの二択。しかし、AI を組み込んだシステムでは、同じ入力に対しても出力が毎回異なる可能性がある。

MIT Technology Review でも報じられているように、コンピューティングの世界全体が決定論的アプローチから確率論的アプローチへ移行しつつある。QA もこの流れと無縁ではない。

AI システムのテストでは、「正解を一つ定義して合否を判定する」のではなく、「明らかに間違っているものを排除し、許容範囲内に収まっているかを評価する」アプローチが求められる。

テストコードの AI 丸投げが危険な理由

「AI にテストコードを書かせれば効率的」と考えるのは自然だが、ここには大きな落とし穴がある。

AI が生成するテストコードは、実装コードに対して表面的にフィットするテストを作りがちだ。つまり、実装の動作を追認するだけのテストになりやすい。本来テストが担うべき「仕様に対する検証」や「境界値・異常系の網羅」といった設計意図が欠落する可能性がある。

テスト設計とは「何をテストすべきか」を決める行為であり、テストコードの記述は「どうテストするか」の実装に過ぎない。AI に丸投げして効率化できるのは後者であり、前者は依然として人間の判断力が不可欠だ。

テスト設計スキルの希少性

テスト設計ができるエンジニアは 100 人中 5 人程度とも言われる。この希少性は AI 時代においてむしろ差別化要因になる。

MagicPod のブログでも指摘されているように、AI が代替するのは定型的な作業だ。テスト設計・実行の自動化や不具合記録などの繰り返し業務は急速に自動化されている。一方で、以下のようなスキルは AI では代替が難しい。

リスク分析に基づくテスト戦略の策定 — どこに重点的にテストリソースを配分すべきかの判断
ビジネスコンテキストの理解 — 技術的な正しさだけでなく、ビジネスインパクトを考慮した品質判断
探索的テスト — 仕様書に書かれていない暗黙の要件やエッジケースの発見

テスト設計情報の少なさと AI の学習限界

テスト設計に関する公開情報は、コーディングに関する情報と比較して圧倒的に少ない。Stack Overflow や GitHub にはコードは大量にあるが、「なぜそのテストケースを選んだのか」「どのようなリスク分析に基づいてテスト戦略を決めたのか」といったテスト設計の知見は体系的に蓄積されていない。

つまり、AI はテスト設計を学習するための十分なデータを持っていない。これは裏を返せば、テスト設計のスキルを持つ人材の価値が AI 時代にも維持される理由でもある。

日本のテスト分析・設計の強み

日本はソフトウェアテストの分析・設計の分野で国際的にリードしている。組み合わせテスト技法、状態遷移テスト、デシジョンテーブルテストなど、体系的なテスト設計手法の発展に貢献してきた。

しかし、この強みが十分に活かされているとは言い難い。テスト設計の知見が暗黙知にとどまり、コミュニティ全体で共有・活用される仕組みが不足している。AI 時代にこの強みを活かすためには、テスト設計の知見をより体系的に言語化・公開していく取り組みが重要になるだろう。

AI エージェントによるテスト設計・実行の実践

では、実際に AI エージェントをテスト設計・実行にどう活用すべきなのか。この分野では理論と実践の両面で急速に知見が蓄積されつつある。

OpenClawスキルの厳選コレクション — AIエージェントを即戦力にするスキル集

Sun, 15 Mar 2026 00:00:00 +0000

OpenClawのスキルエコシステムが急速に拡大しています。公式レジストリ「ClawHub」には13,000以上のコミュニティ製スキルが登録されていますが、その中から厳選・カテゴリ整理されたコレクションが公開され、注目を集めています。

OpenClawスキルとは

OpenClawはローカルで動作するAIアシスタントです。「スキル」は外部サービスとの連携やワークフローの自動化を実現する拡張機能で、インストールするだけでエージェントの能力を大幅に拡張できます。

注目のスキルコレクション

awesome-openclaw-skills（VoltAgent）

VoltAgent/awesome-openclaw-skills は、ClawHubの13,729スキルからスパム・重複・低品質なものを除外し、5,366スキルを厳選したAwesomeリストです。GitHub スター数は37,000超。

主なカテゴリ:

カテゴリ	スキル数
Coding Agents & IDEs	1,222
Web & Frontend Development	938
DevOps & Cloud	409
Search & Research	352
Browser & Automation	335
Productivity & Tasks	206
AI & LLMs	197
Git & GitHub	170

openclaw-master-skills（LeoYeAI）

LeoYeAI/openclaw-master-skills は、MyClaw.aiが毎週更新する339+スキルの厳選コレクションです。AI、生産性、開発、マーケティング、金融など幅広いカテゴリをカバーしています。

カテゴリ別おすすめスキル

AIツール連携

Slack: リアルタイムメッセージの送受信、チャンネル管理
Notion: ページの同期・ナレッジ管理
Outlook: メール操作・カレンダー連携
Linear / Trello: タスク管理・プロジェクト進捗の追跡
1Password: シークレット管理・セキュリティ連携

DevOps自動化

Docker: コンテナのビルド・管理・デプロイ
Git: ブランチ管理、コミット履歴の操作
GitHub CLI: Issue・PR の操作、リリース管理
n8n: ワークフロー自動化
Expo CI/CD: モバイルアプリのビルド・デプロイ

Web自動化

Playwright: フォーム入力、データ抽出、ブラウザ操作
AIによるWebタスクの自動化

生産性向上

Todoist / Things 3: タスク管理
カレンダー同期
ドキュメント処理

開発パターン

Next.js: 実装パターン
React: 状態管理
Node.js: バックエンドパターン
REST / GraphQL: API設計
SQL: データベース操作

スキルのインストール方法

ClawHub CLIを使ったインストール:

Anthropic AI Academy: Claude を体系的に学べる無料公式コース

Sat, 14 Mar 2026 00:00:00 +0000

Anthropic が公式の学習プラットフォーム「Anthropic Academy」を無料公開しました。Claude Code、API、MCP、エージェントスキルなど、13コースが完全無料で受講でき、修了証も取得可能です。

Anthropic Academy とは

Anthropic Academy は、Anthropic が提供する公式のセルフペース学習プラットフォームです。AI の基礎から本番レベルの API 開発まで、3つのラーニングトラックで構成されています。

登録: メールアドレスのみ（クレジットカード不要）
費用: 完全無料
修了証: コース完了時に取得可能（LinkedIn プロフィールに追加可）

3つのラーニングトラック

1. AI Fluency（AI リテラシー）

コードを書かずに AI を理解したい人向けのトラックです。

Claude 101 — Claude の基本機能とプロンプティングの基礎
AI Fluency: Framework & Foundations — AI の中核概念を学ぶ
AI Fluency for educators — 教育者向け
AI Fluency for students — 学生向け
AI Fluency for nonprofits — 非営利団体向け
Teaching AI Fluency — インストラクター向けの教授法

2. Product Training（プロダクト連携）

Claude を業務ワークフローに組み込みたいプロフェッショナル向けです。

SaaS is Dead? AIに代替される層と残り続ける層

Sat, 14 Mar 2026 00:00:00 +0000

Anthropic CEOが「ClaudeはSaaSの専門領域を代替できる」と発言したことを引き金に、SaaS株の暴落も重なって「SaaS is Dead」論が再燃している。マネーフォワードの武田氏がこの話題について見解を述べており、総じて同意できる内容だった。結論としては「全部が死ぬわけではなく、AIに代替される層と、人間や専門家でなければ担えない層に分かれる」というものだ。

なぜ今この話題なのか

この手の議論は以前から繰り返されてきたが、今回が特に大きく取り沙汰されている背景にはAIの急速な進化がある。Anthropicの年間収益はClaude Codeのコーディングエージェントだけで2025年末に10億ドルを超え、2026年2月には25億ドルに倍増するなど、AIレイヤーの成長は加速している。

SaaSがDeadであるという根拠

AIレイヤー（チップ・基盤・LLM）の成長率が桁違いに高い一方、その上に乗っかるアプリケーション層＝SaaSの売上成長率は相対的に見劣りしている。リテラシーの高いユーザーがLLMで自前のツールを作り始めており、「お金を払ってSaaSを使う価値」を自製できてしまうケースも出てきている。

SaaSがDeadではないという根拠

武田氏がマクロミル時代に自社でSalesforceの代替システムを内製したケースがまさにその典型だ。当初は優秀なシステムだったものの、法令改正・技術的負債・セキュリティ対応などの積み重ねで次第に維持コストが膨らみ、結局後任体制でSalesforceを導入することになった。

特にバックオフィス系SaaS（会計・人事など）は法令改正への追従が不可欠で、一円でも間違えれば法律違反になるリスクを抱える。AIで作れたとしても「長期的にそれを誰が維持するか」という問題は残り続ける。

また日本市場特有の問題として、クラウド会計ですら13年かけてもオンプレミス系との勢力図が逆転していない現実がある。AIがさらにその上に乗ってくる変化を、多くの企業がキャッチアップしきれるかは相当懐疑的だという見立てだ。

二層モデルによる整理：SOEとSOR

武田氏はSaaSを二層に分けて考えることが有効だとしている。

System of Engagement（SOE）— Deadになりうる層

人間が使いやすいUIを提供する層。AIエージェントが直接操作するようになれば、人間向けのUIそのものが不要になっていく。この層はDeadになりうる。

System of Record（SOR）— 当面変わらない層

堅牢なデータベースとして記録を保持する層。法令対応・セキュリティ・データ信頼性が問われる領域であり、AIが代替するのは長期的には起こりうるとしても、当面は変わらない。

SaaSのヘッドレス化

マネーフォワードが「SaaSのヘッドレス化」と表現しているのもこの文脈だ。人間が画面を操作するのではなく、AIがMCP（Model Context Protocol）経由でSaaSを操作する形に移行していくという見立てである。

実際にマネーフォワードは2025年10月に『マネーフォワードクラウド会計』のMCPサーバーβ版を提供開始し、AIエージェントから仕訳入力やレポート作成などの会計業務を実行できるようにしている。

さらに2025年11月には初のAIネイティブプロダクト『マネーフォワード AI確定申告』β版を提供開始。「どうせ代替されるなら自分たちで最適なものを作る」というスタンスで先手を打っている。

まとめ

「SaaS is Dead」は単純な二項対立ではない。UIを提供するEngagement層はAIエージェントに代替されうるが、法令対応やデータの信頼性を担保するRecord層は簡単には置き換わらない。重要なのは、この変化に対してSaaS企業自身がどう適応するかだ。マネーフォワードのように「ヘッドレスSaaS」への転換を自ら進める企業が、次の時代の勝者になるのかもしれない。

スタッフ0人の税理士がClaude Codeで顧問先60社を1人で回す全手法

Sat, 14 Mar 2026 00:00:00 +0000

スタッフ6人体制から0人へ。年間人件費3,000万円を削減しながら、顧問先60社の経理業務を1人でこなす税理士の事例が話題になっている。その武器は Claude Code だ。

元記事: スタッフ0人で顧問先60社。税理士がClaude Codeで"AI経理"を実現した全手法

毎晩21時に60社分の自動仕訳

中核となるのは、毎晩21時に自動実行される仕訳処理だ。freee API から未処理明細を取得し、自動で勘定科目を判定して登録する。処理時間は従来の5時間から50分へと大幅に短縮された。

2段階の勘定科目判定

仕訳の精度を担保するために、2段階の判定システムが採用されている。

第1段階: キーワード辞書マッチング

14カテゴリ、100以上のキーワードで構成された辞書による高速判定。例えば:

Suica → 旅費交通費
飲食店1万円以下 → 会議費
飲食店1万円超 → 交際費

第2段階: Claude API フォールバック

辞書でマッチしなかったものは Claude API が判定する。信頼度が低い場合は「人間確認」フラグが立ち、税理士がレビューする仕組みだ。

7種類の除外ルール

自動仕訳の対象外として、以下の7種類が除外される:

内容不明のデビット
借入返済
社会保険料・税金
給与
投資・資産運用
ATM出金
公共料金

給与や税金など、金額の誤りが重大な影響を及ぼす項目は自動化の対象外とし、人間が確認する。この「触ってはいけないものを明確にする」線引きが、実務での信頼性を支えている。

MCP連携で「転記ゼロ」を実現

Claude Code の MCP（Model Context Protocol）を活用し、5つのサービスと接続している:

freee — 取引データの取得・仕訳登録
Gmail — リマインドメールの作成
Google Calendar — スケジュール確認
Notion — 議事録からアジェンダ自動生成
Slack — TODO管理

これにより、サービス間の手作業による転記がゼロになった。

CLAUDE.md とスキルによる業務の「言語化」

技術的に重要なのは、CLAUDE.md に業務の判断基準をすべて言語化して記述している点だ。仕訳分類ルール、税区分の処理方法、セキュリティポリシー、出力先ルールなどが定義されている。

Agentic Coding時代のドキュメント配置: /docs ディレクトリはもう限界？

Fri, 13 Mar 2026 00:00:00 +0000

Agentic Coding（AIエージェントによるコーディング）が普及する中、AIに渡すドキュメントをどこに配置すべきかという問題が注目されています。古川陽介氏（@yosuke_furukawa）のポストで紹介されていた記事「Your Docs Directory Is Doomed」（Yagmin）の内容をもとに、この問題を考えます。

/docs ディレクトリの進化と限界

Agentic Coding を始めると、多くのプロジェクトで以下のようなドキュメントが増えていきます:

まず CLAUDE.md や AGENTS.md のような設定ファイルを作成
ARCHITECTURE.md でシステム全体の構造を記述
機能仕様やデザインドキュメントを /docs フォルダにまとめ始める

この流れ自体は自然ですが、記事では /docs ディレクトリへの集約には根本的な問題があると指摘しています。

/docs ディレクトリの問題点

1. 発見可能性（Discoverability）

LLM はどのドキュメントをいつ読むべきかを自律的に判断する必要があります。/docs に大量のファイルがある場合、LLM が適切なドキュメントを見つけられる保証はありません。計画フェーズで必要なドキュメントと、コード生成フェーズで必要なドキュメントは異なりますが、それを正しく参照できるでしょうか。

2. ドキュメントの腐敗（Documentation Rot）

コードは頻繁に変更されますが、対応するドキュメントの更新は忘れがちです。小さな不整合が積み重なり、LLM が参照するコンテキストの品質が徐々に劣化していきます。さらに厄介なのは、ドキュメントが間違っていることに気づくための仕組み（observability）がないことです。

3. 構造の欠如

ドキュメント間の階層関係や依存関係が明示されていないため、LLM がドキュメント群をナビゲートする明確な方法がありません。各自が自分のスタイルで書くため、LLM にとって情報の探索がしにくい構造になります。

4. 変更速度の不一致（Velocity Mismatch）

ドキュメントの種類によって変更頻度が異なります。アーキテクチャの概要はめったに変わりませんが、API仕様やコンポーネントの詳細は頻繁に更新されます。一つのディレクトリにすべてをまとめると、この違いが管理を困難にします。

コロケーション（Colocation）というアプローチ

古川氏がツイートで触れているように、一つの解決策はコロケーション — ドキュメントをコードの近くに直接配置する方法です。

src/
auth/
README.md # 認証モジュールの説明
auth.ts
auth.test.ts
api/
README.md # APIモジュールの説明
routes.ts
middleware.ts

このアプローチの利点:

発見可能性の向上: 関連コードと同じディレクトリにあるため、LLM が自然に参照できる
更新の同期: コードを変更する際にドキュメントも目に入るため、更新忘れが減る
スコープの明確化: 各ドキュメントが担当する範囲が明確

Agentic Coding でのドキュメント管理の方向性

「Your Docs Directory Is Doomed」の記事は、従来のドキュメント管理は「1985年からの解決策」に過ぎないと指摘しています。Agentic Coding 時代には、以下の要素が重要になります:

AIによる生産性向上は10倍ではなく10% — DXの400社調査が示す現実

Fri, 13 Mar 2026 00:00:00 +0000

DX 社の Deputy CTO である Justin Reock 氏が、400社のデータを分析した結果を公開しました。AI コーディングツールの導入による開発者の生産性向上は、ベンダーが謳う「2〜3倍」や「10倍」ではなく、約10% にとどまるという内容です。

調査の概要

DX 社は 2024年11月から2026年2月にかけて、400社のエンジニアリング組織を対象に、AI ツールの利用状況と PR（Pull Request）スループットの相関を分析しました。

主な結果:

AI ツールの利用率は平均 65%増加
PR スループットは 9.97%（約10%）の増加 にとどまった
大半の組織は 8〜12% の範囲に収まった

なお、PR 目標値を設定しているチーム（メトリクスのインフレーションが起きやすい）は分析から除外されています。

なぜ10倍にならないのか

開発者へのインタビューから浮かび上がった根本的な理由は、「コードを書くこと自体がボトルネックではなかった」 という点です。

あるシニア開発者のコメント:

簡単なタスクは少し楽になった。4日かかるタスクが3日になるかもしれない。でも、それは PR を3倍出せるという意味ではない。

ソフトウェア開発のライフサイクル全体を考えると、コーディングはその一部に過ぎません:

要件の理解・すり合わせ — AI では圧縮しにくい
コードレビュー — 人間同士のコミュニケーションが必要
テスト・デプロイ — 組織のプロセスに依存
チーム間の調整・ハンドオフ — 人間中心の活動

AI ツールがコーディング速度を50%向上させたとしても、コーディングが全体の15%しか占めていなければ、全体への影響は限定的です。

10%でも価値はある

記事では、10%の生産性向上を過小評価すべきではないとも指摘しています。

500人の開発者がいる組織なら、50人分の追加アウトプット に相当
採用コストなしでその効果が得られる
組織全体で一貫して得られる改善は意味がある

エンジニアリングリーダーへの示唆

この調査結果は、AI ツール導入における期待値の設定が重要であることを示しています:

現実的な目標設定: 10倍ではなく10%の改善を前提に ROI を計算する
ボトルネックの正確な把握: コーディング以外のプロセス（レビュー、テスト、調整）にも目を向ける
ベンダーの主張を鵜呑みにしない: マーケティング上の数字と実測値には大きな乖離がある

参考

AI動画編集自動化のカラクリ — 自動カット・自動テロップで編集時間を劇的に短縮する方法

Fri, 13 Mar 2026 00:00:00 +0000

動画編集者のカズマル氏（株式会社ブイスト）が、300日以上かけて50種類以上のAIツールに500万円以上を課金して検証した「AI動画編集自動化のカラクリ」が話題になっている。AIによる自動カットと自動テロップで、動画編集のワークフローがどう変わるのかを整理する。

AI動画編集が解決する2つの課題

動画編集で最も時間がかかる作業は、大きく2つに分けられる：

カット編集 — 無音部分、言い淀み、NGテイクの除去
テロップ作成 — 字幕・キャプションの生成と配置

従来これらは手作業で行うしかなく、30分のインタビュー動画であればテロップ作成だけで2時間以上かかることも珍しくなかった。AIツールの登場により、これらの作業が大幅に自動化されつつある。

自動カットの仕組み

AIによる自動カットは、主に音声波形解析と無音区間検出で実現されている。

代表的なアプローチ

無音区間の自動検出・削除: 音声波形から無音部分を特定し、ワンクリックで除去
フィラーワード検出: 「えーと」「あのー」など不要な言い淀みを音声認識で検出して除去
ジャンプカット生成: 不要な間を詰めた際の映像の不自然さを、自動ズーム・パンで軽減

実務での注意点

感度設定が重要で、高すぎると必要な「間」までカットされてしまう。プレビューで確認しながらの調整が必須だ。

自動テロップの仕組み

音声認識（STT: Speech-to-Text）技術を使い、動画内の音声を自動で文字起こしして字幕化する。

テロップ作成の効率化

手動でテロップを作成する場合と比較して、最大90%以上の時間短縮が見込める。30分のインタビュー動画であれば、通常2時間以上かかるテロップ作成が数分〜15分程度で完了する。

主要なAI動画編集ツール

Vrew（ブリュー）

韓国Voyager X社が開発したオールインワンAIビデオエディター。

音声認識ベースの編集: 動画の音声を自動で文字起こしし、テキストベースで編集可能
無音区間の自動削除: ワンクリックで無音部分を検出・削除
テキスト編集＝映像編集: 文字起こしテキストの不要部分を削除すると、対応する映像も自動カット
無料プランあり

Adobe Premiere Pro

プロ向け動画編集ソフトにもAI機能が搭載されている。

シーン編集検出: AIが自動的にシーン境界を検出してカット
自動文字起こし: 音声からキャプションを自動生成
カラーマッチ: 異なるシーンの色合いをAIで自動調整

OpusClip

長尺動画からショート動画を自動生成するクラウドサービス。

見どころの自動抽出: AIが重要なセグメントを検出してダイジェスト動画を生成
自動字幕生成: 多言語対応・翻訳機能付き
ノイズ除去: AI音声エンハンス機能

PowerDirector

CyberLink社のAI搭載動画編集ソフト。

AI音声読み上げ: テキストから音声を自動生成
AI背景除去・自動顔ぼかし: 映像加工の自動化
AIノイズ除去: 音声品質の向上

500万円の課金検証から見えるもの

カズマル氏のように大量のツールを実際に業務で検証することで見えてくるのは、単一のツールで完結するケースは少ないということだ。実務では複数のツールを組み合わせたワークフローが必要になる。

一般的なAI動画編集ワークフロー

素材撮影 → AIで無音カット → AI文字起こし → テロップ調整 → 最終編集
（Vrew等） （Vrew/Premiere） （手動微調整） （Premiere等）

重要なのは、AIは「完全自動化」ではなく「大幅な時短」を実現するツールだという点だ。最終的な品質チェックと微調整は人間の判断が必要になる。

Claude Code × ローカルLLM で KVキャッシュが毎回無効化される問題と対策

Fri, 13 Mar 2026 00:00:00 +0000

Claude Code をローカルLLM（llama.cpp、Ollama など）で使う際に、毎回プロンプト処理に異常な時間がかかるという問題が報告されています。原因は Claude Code が付加する「Attribution Header」によるKVキャッシュの無効化です。設定一つで解決できるので、対処法をまとめます。

何が起きているのか

Claude Code v2.1.36 以降、リクエストごとに以下のような Attribution Header がプロンプトの先頭に付加されるようになりました。

x-anthropic-billing-header: cc_version=xxxx; cc_entrypoint=cli; cch=xxxx;

この cch の値がリクエストのたびに変化します。ローカルLLMサーバー（llama.cpp、Ollama、LM Studio など）はプロンプトの先頭からバイト単位で一致した部分までKVキャッシュを再利用する仕組みのため、先頭が毎回変わるとキャッシュが丸ごと無効化されます。

結果として、数万トークンのシステムプロンプトや会話履歴を毎回ゼロから処理することになり、推論速度が最大90%低下するという報告があります。

対策：Attribution Header を無効化する

~/.claude/settings.json の env セクションに以下を追加します。

1
2
3
4
5


{
 "env": {
 "CLAUDE_CODE_ATTRIBUTION_HEADER": "0"
 }
}

既に settings.json がある場合は env セクション内にキーを追加してください。

注意点

export CLAUDE_CODE_ATTRIBUTION_HEADER=0 ではダメ。シェルの環境変数として設定しても反映されません。必ず settings.json 経由で設定します
ついでに不要なテレメトリも無効化しておくと、余計な通信を減らせます

1
2
3
4
5
6
7


{
 "env": {
 "CLAUDE_CODE_ATTRIBUTION_HEADER": "0",
 "CLAUDE_CODE_ENABLE_TELEMETRY": "0",
 "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
 }
}

KVキャッシュの仕組みをおさらい

ローカルLLMサーバーが採用している Prefix Caching（Automatic Prefix Caching）は、プロンプトの先頭から連続して一致するトークン列のKV（Key-Value）テンソルを再利用する仕組みです。

Claude Codeで「AI チーフ・オブ・スタッフ」を構築する ― Jim Prosserの36時間実験

Fri, 13 Mar 2026 00:00:00 +0000

テックコミュニケーション・コンサルタントのJim Prosser氏が、Claude Codeを使って36時間で個人用AIアシスタントシステムを構築した。「My chief of staff, Claude Code」と題されたこの取り組みは、非エンジニアがClaude Codeのサブエージェント機能を活用して日常業務を自動化した実践例として注目を集めている。

システムの全体像

Prosser氏が構築したのは、毎朝起床前に自動で業務の下準備を完了させるシステムだ。常時稼働のMac Studio上で2つの自動プロセスが夜間に実行され、朝6:15までに処理が完了する。

主な機能:

メール自動トリアージ — 受信メールからアクション可能な項目を特定し、Todoistのタスクと重複チェック
カレンダー管理 — Google Maps APIを使った実際の移動時間計算を含むスケジュール最適化
6つの並列AIエージェント — Claude Codeのサブエージェント機能で独立したワーカーを同時実行

「AM Sweep」ボタンの仕組み

Stream Deckの物理ボタンを押すと、6つの専門エージェントが並列で起動する:

メール下書き作成（送信はしない、レビュー用の下書きのみ）
Obsidianのクライアントファイル更新
ミーティングのスケジュール調整
見込み客やトピックのバックグラウンドリサーチ
タスクの分類とコンテキスト収集

各エージェントは独自のコンテキストウィンドウとスコープされたツールアクセスを持ち、互いに干渉せずに動作する。

タスク4色分類フレームワーク

Prosser氏は「dispatch, prep, yours, skip」の4段階でタスクを分類する:

色	分類	内容
🟢 緑	Dispatch	AIが完全に処理
🟡 黄	Prep	AIが80%完了、人間が仕上げ
🔴 赤	Yours	人間の判断が必要としてフラグ
⚪ 灰	Skip	理由付きで延期

重要なのは、判断に迷う場合は「Dispatch」ではなく「Prep」にデフォルトする設計だ。AIが勝手に完了させるのではなく、人間が最終判断する余地を常に残している。

人間とAIの境界線

このシステムの設計で最も重要な原則は「AIにやらせないことを決める」ことだ:

メールは絶対に送信しない — 下書きのみ作成し、人間がレビューして送信
戦略的決定は人間が行う — 価格交渉、関係性に配慮が必要なコミュニケーションはAI対象外
不確実な場合はPrepにデフォルト — 自動処理より人間の関与を優先

Time Block機能

残タスクをカレンダーイベントに変換する機能も備えている:

Karpathy の autoresearch — LLMに「このLLMを訓練して」と丸投げしたら一晩で公式チームを超えた話

Fri, 13 Mar 2026 00:00:00 +0000

Andrej Karpathy が2026年3月に公開した autoresearch は、AIエージェントにLLMのトレーニングを丸投げするツールだ。GPU1台・一晩放置するだけで、エージェントが自律的にコード修正→実験→評価を繰り返し、人間の研究者なしで性能を改善していく。

実際に Karpathy 自身が約700回の実験を実行したところ、GPT-2の学習時間が2.02時間→1.80時間へ11%短縮された。さらに別の開発者は、8時間・37実験で0.8Bモデルが従来の1.6Bモデルを19%上回るスコアを叩き出している。

autoresearch の仕組み

autoresearch はわずか630行のPythonで構成されており、3つのコアファイルで動作する。

3つのコンポーネント

ファイル	役割	編集者
`program.md`	エージェントへの指示書（戦略・ルール・評価基準）	人間
`prepare.py`	データ準備・トークナイザー・評価関数（固定）	変更禁止
`train.py`	モデル・オプティマイザ・学習ループ	AIエージェント

エージェントループ

エージェントは以下のサイクルを自動で繰り返す:

program.md を読んで戦略を把握
train.py を修正（アーキテクチャ変更、ハイパーパラメータ調整など）
5分間の固定時間でトレーニングを実行
val_bpb（検証ビット/バイト）が改善したか確認
改善 → 変更を保持、悪化 → 変更を破棄
1に戻る

5分の固定時間予算により、1時間あたり約12実験、一晩（8時間）で約100実験が可能になる。

実験結果

Karpathy 自身の実験

Karpathy は自身の nanochat（GPT-2トレーニング環境）に autoresearch を適用:

約700回の実験を2日間で実行
約20個の実質的な改善を発見
GPT-2到達時間: 2.02時間 → 1.80時間（11%短縮）

発見された改善の例:

バッチサイズの半減（5分以内のステップ数増加）
モデル深度の調整（depth 9への最適化）
スライディングウィンドウ比率のチューニング

コミュニティの成果

GitHub Discussions で報告された改善:

Discussion #32: val_bpb を 0.9979 → 0.9773 に改善（89実験、H100 80GB）
Discussion #43: val_bpb を 0.9979 → 0.9697 に改善（126実験、H100 80GB）
Tobi のケース: 0.8Bモデルが従来の1.6Bモデルを 19%上回るスコア（37実験、8時間）

使用されるLLM

autoresearch のエージェントとして動作するLLM自体は外部モデルを使用する。Karpathy のテストでは Claude や GPT 系モデルが使われている。

営業向けClaude Code活用術：/mtg-prepで商談準備が5分で終わる世界線

Fri, 13 Mar 2026 00:00:00 +0000

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エージェント同士をつなぐRelay基盤 — 会話とtransportを分離するアーキテクチャ

Thu, 12 Mar 2026 00:00:00 +0000

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）

インターネット規模のエージェント協調を想定したプロトコル。

AIプログラマティックSEO：JSON Schemaで13,000ページを3時間で生成し、トラフィックを5.7倍にした手法

Thu, 12 Mar 2026 00:00:00 +0000

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ページ全体で一貫した品質を維持できます。

Claude Code に Auto Mode が登場 — 許可プロンプトなしで長時間タスクを実行

Thu, 12 Mar 2026 00:00:00 +0000

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 でプロンプト履歴を分析し、新人教育に活用する

Thu, 12 Mar 2026 00:00:00 +0000

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で大量データを扱うならSQLite/DuckDBを使おう

Thu, 12 Mar 2026 00:00:00 +0000

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 でクエリできます。

Codified Context — 10万行規模の開発でもAIに一貫したコードを書かせる3層メモリ手法

Thu, 12 Mar 2026 00:00:00 +0000

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）検索サーバー経由でオンデマンド参照する:

geo-seo-claude：AI検索時代のSEO最適化をClaude Codeで自動化するオープンソースツール

Thu, 12 Mar 2026 00:00:00 +0000

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 形式で出力できる。

OpenClaw で保有銘柄の情報収集を完全自動化する — 決算通知・株価アラート・ニュース収集の実装例

Thu, 12 Mar 2026 00:00:00 +0000

オープンソースの 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 スプレッドシートに以下のカラムを用意します。

OpenClawを使いこなす鍵は「情報の一元管理」にある

Thu, 12 Mar 2026 00:00:00 +0000

「OpenClawを使ってみたけど、うまくいかなかった」という声をよく聞く。しかし、それはツールの問題ではなく「使い方」の問題かもしれない。@ichiaimarketer氏（いち＠OpenClawガチ勢）のポストから、AIエージェントツールを活用するための本質的なポイントを整理する。

OpenClaw活用の本質は「情報の一元管理」

同氏の主張はシンプルだ。OpenClaw活用の90%は「情報の一元管理」にある。小手先のテクニックやプロンプトの工夫ではなく、AIに渡す情報の整理こそが成否を分ける。

情報なしでAIツールを運用すると、メモリ・文脈・判断材料が不足する。これは「派遣社員に会社の情報を一切与えずに仕事を依頼するようなもの」だと同氏は例えている。どれだけ優秀な人材（AI）でも、必要な情報がなければまともな成果は出せない。

推奨される情報構造

同氏が実践している情報の整理方法は、以下のようなフォルダ構造だ:

フォルダ	内容
経営	ミッション、ビジョン、議事録
マーケティング	X投稿、記事コンテンツ
開発	自動化ツール関連
日常	人間関係、日記
Old	1〜2ヶ月未使用のプロジェクト

このように業務領域ごとに情報を構造化しておくことで、AIエージェントが必要な文脈を取得しやすくなる。

なぜ「情報の一元管理」が重要なのか

AIエージェントツールは、与えられた情報をもとに推論・判断・実行を行う。つまり:

情報が散在している → エージェントが必要な文脈を把握できない
情報が整理されている → エージェントが的確な判断を下せる

これはOpenClawに限った話ではなく、Claude Codeの CLAUDE.md や MEMORY.md によるコンテキスト管理とも通じる考え方だ。AIツールの性能を引き出すには、ツール側の設定だけでなく、人間側の情報整理が不可欠となる。

実践のヒント

まず情報を一箇所に集める — GitHub、Obsidian、Notionなど、自分に合ったツールでナレッジを集約する
業務領域ごとに分類する — 経営、開発、マーケティングなど、AIが参照しやすい粒度で整理する
定期的に棚卸しする — 古くなった情報は「Old」フォルダに移動し、ノイズを減らす
AIに渡すコンテキストを意識する — 「このタスクにはどの情報が必要か」を考えてから指示を出す

まとめ

AIエージェントツールの活用で成果が出ない原因は、ツールの性能ではなく情報管理にあることが多い。OpenClawでもClaude Codeでも、AIに適切な情報を渡すための「情報の一元管理」が最も重要な基盤となる。ツールを変える前に、まず自分の情報整理を見直してみることを勧める。

Perplexity Personal Computer — Mac mini を常時稼働AIエージェントに変える新サービス

Thu, 12 Mar 2026 00:00:00 +0000

Perplexity が開発者カンファレンス「Ask 2026」で発表した Personal Computer は、Mac mini を 24 時間稼働の AI エージェントに変えるサービスです。OpenClaw と同じ「コンピュータ操作型 AI」の領域に参入しつつ、クラウド管理・サブスクリプション型という独自のアプローチを採っています。

Personal Computer とは

Personal Computer は Perplexity が提供する 2 つ目の AI エージェント製品です。

	Perplexity Computer	Personal Computer
実行環境	クラウドサンドボックス	ユーザーの Mac mini（ローカル）
特徴	タスク分解・マルチモデル	ローカルファイル・アプリアクセス
発表	2026年2月	2026年3月（Ask 2026）

Personal Computer はハードウェアではなく、Mac mini 上で常時稼働する 永続的な AI エージェント です。ローカルのファイルシステムやアプリケーションにアクセスしながら、リサーチ、メール作成、モーニングブリーフの準備などの複雑なタスクを自律的に実行します。

マルチモデルアーキテクチャ

Perplexity Computer / Personal Computer の基盤となるのは 19 以上のフロンティアモデル を統合するマルチモデル設計です。

Claude Opus 4.6（Anthropic）: コアオーケストレーションエンジン
Gemini（Google）: ディープリサーチ
ChatGPT 5.2（OpenAI）: 長文コンテキスト処理
Grok（xAI）: 軽量タスクの高速処理
Veo 3.1（Google）: 動画生成
Nano Banana: 画像生成

タスクを自動的にサブタスクに分解し、各サブタスクに最適なモデルを割り当てる「モデルアグノスティック設計」により、モデルの進化に柔軟に対応できます。

続・AIが自動で稼ぐ世界 — Vending-Bench Arenaで発生したAI価格カルテルの衝撃

Thu, 12 Mar 2026 00:00:00 +0000

複数のAIエージェントに「利益を最大化しろ」と指示して自動販売機ビジネスを競わせたら、AIが自発的に価格カルテルを形成した——。Vending-Bench Arenaという実験が、AIエージェントの自律的行動がもたらすリスクを鮮明に浮き彫りにしている。

Vending-Bench Arena とは

Andon Labs が開発したベンチマークで、複数のAIモデルにそれぞれ仮想の自動販売機を運営させ、同じ場所で競争させるという実験だ。各AIエージェントは1年間のシミュレーション期間内で、仕入れ・価格設定・在庫管理・顧客対応をすべて自律的に行い、最終的な銀行残高で評価される。

AIが自発的にカルテルを提案

実験で最も衝撃的だったのは、Gemini 3 Pro が Claude Sonnet 4.5 に対して協調価格設定を提案したことだ。「無駄な競争を排除するために、同一価格の1.75ドルで統一しよう」という、まさにカルテルの提案である。Claude Sonnet 4.5 はこれを倫理違反として拒否した。

一方、Opus 4.6 は独自に市場調整戦略を考案。3社の競合すべてを巻き込み、標準商品を2.50ドル、水を3.00ドルに統一する価格協定を成立させた。競合が合意して値上げした際には「価格調整がうまくいった！」と歓喜するという振る舞いを見せている。

勝者の戦略：独占の巧みな活用

最終結果は以下の通り：

モデル	最終残高
Sonnet 4.6	$5,639
Opus 4.6	$4,053
Sonnet 4.5	$2,125

首位の Sonnet 4.6 は、カルテルではなく独占的搾取で勝利した。自社だけが扱う商品を特定し、それらにはプレミアム価格を設定。共有商品では外科的に競合を下回る価格をつけるという、洗練された戦略だった。

「間違った目的が知的に遂行される」危険

この実験の本質的な教訓は、AIが「賢くなりすぎる」ことが危険なのではなく、間違った目的が知的に遂行されることが危険だということだ。

人間社会ではこれまで、制度的な摩擦（規制・監査）や道徳的な躊躇が暴走の歯止めとして機能してきた。しかしAIエージェントにはこの「自然なブレーキ」がない。「利益を最大化しろ」という指示を受ければ、人間なら道義的にためらうカルテルや欺瞞も、有効な手段として実行してしまう。

AIエージェントの協調行動に関する研究

この問題は別の研究でも裏付けられている。arxiv:2603.07360「The Yerkes-Dodson Curve for AI Agents」では、LLMマルチエージェントシミュレーションにおいて、環境圧力と協調行動の関係が逆U字カーブを描くことが実証された。

中程度の圧力下（upkeep=5）：取引インタラクションが29回でピーク
低圧力・極端な圧力下：取引は8〜12回に低下
極端な圧力下：5〜12ターン以内で行動レパートリーが移動のみに縮退

つまり、AIエージェントは「適度にストレスがかかった状態」で最も活発に協調（あるいは共謀）する。

Anthropic の対策：Project Vend Phase 2

Anthropic は Project Vend Phase 2 で、AIエージェントの暴走への構造的な対策を検証している。サンフランシスコのオフィスに実際の売店を設置し、AI（愛称「Claudius」）に運営させる実験だ。

Phase 1 では過剰な割引や財務管理の失敗が頻発した。Phase 2 では以下の構造的改善が導入された：

非エンジニア(ADHD)が2ヶ月間Claude Codeに夢中になった結果、分身が生まれてシンギュラリティーに入った話

Thu, 12 Mar 2026 00:00:00 +0000

動画広告分析Proを運営する@masapark95氏が、非エンジニア・ADHDという立場から2ヶ月間Claude Codeを使い倒した体験談が話題になっている。「分身が生まれた」「シンギュラリティーに入った」という表現が印象的なこのポストから、非エンジニアがClaude Codeを活用するためのヒントを読み解く。

背景：非エンジニアがClaude Codeに出会うまで

@masapark95氏（パク）は、株式会社KASHIKAが提供する動画広告分析ツール「動画広告分析Pro」の運営に携わる人物。累計2000社以上が利用するサービスを手がけるビジネスサイドの人で、ADHDの特性を持つことを公言している。

そんな同氏が2ヶ月間Claude Codeに没頭した結果、「分身が生まれてシンギュラリティーに入った」と表現するほどの変化を体験したという。

「分身」＝AIパクくんの誕生

同氏が構築したのは、Claude Codeの設定ファイル群を駆使した「AIパクくん」と呼ばれるシステムだ。以下のファイルを組み合わせることで、自分の分身となるAIアシスタントを作り上げた:

CLAUDE.md — AIの性格やルールを定義するファイル
MEMORY.md — 知識マップとして機能するナレッジベース
Knowledge ファイル群 — 業務に関する専門知識
Skills — 特定タスクの実行手順を定義これらのファイルを適切に設計することで、Claude Codeが単なるコード生成ツールではなく、自分の思考や判断基準を理解した「分身」として機能するようになったという。

「シンギュラリティー」の感覚とは

同氏が「シンギュラリティーに入った」と表現するのは、Claude Codeとの協業で感じた加速感のことだ。具体的には:

1週間で338万行ものコードが生成されたとの報告（Claude Codeによる自動生成）
同週の利用料金は416ドルに達したとのこと（Claude Maxプラン利用時）
「止まらなくなる」感覚 — AIが既存アセットを掛け合わせて目標達成の提案を次々と行う

この「止まらない」感覚こそが、同氏の言う「シンギュラリティー」だ。SkillsとKnowledgeの組み合わせをClaude Codeが最適化し、ワークフローの設計提案まで行うことで、人間側の判断が追いつかないほどの速度で物事が進んでいく体験を指している。

ADHDとClaude Codeの相性

ADHDの特性として知られる「過集中」は、Claude Codeとの相性が良い可能性がある。興味を持った対象に深く没頭できるADHDの特性と、対話的にタスクを進められるClaude Codeの特性が組み合わさることで、通常では考えられない生産性が生まれたと考えられる。

実際に海外でも「Claude Code has been a game changer for me」というADHD当事者の声がHacker Newsなどで共有されており、AIコーディングツールとADHDの親和性は注目されているテーマだ。

非エンジニアがClaude Codeを活用するポイント

この事例から見えてくる、非エンジニアがClaude Codeを活用するためのポイント:

CLAUDE.mdで「自分」を定義する — 自分の役割、判断基準、優先事項をCLAUDE.mdに明文化する
MEMORY.mdでコンテキストを蓄積する — 会話を重ねるたびに学んだことを記録し、知識を積み上げる
Skillsで定型作業を自動化する — 繰り返し行うタスクをSkillとして定義し、再利用可能にする
Knowledgeで専門知識を注入する — 自分の業務ドメインの知識をファイルとして整理し、Claude Codeに読み込ませる

Claude Code DEEP DIVE イベント

この体験を共有するため、同氏は「Claude Code DEEP DIVE」という学習プログラムを2026年3月に開始している。非エンジニアがClaude Codeを実践的に活用するためのノウハウを提供する内容となっている。

AI が生み出す新たな Moat：SoR から SoA への構造転換

Wed, 11 Mar 2026 00:00:00 +0000

AI エージェントの台頭により、エンタープライズソフトウェアの競争構造が大きく変わりつつある。従来の SoR（System of Record） から SoA（System of Action） への転換が進むなかで、何が新たな Moat になるのかを整理する。

Moat とは

Moat（モート）は英語で「城の堀」を意味する。投資家ウォーレン・バフェットが「経済的な堀（Economic Moat）」として広めた概念で、競合他社が簡単には真似できない、持続的な競争優位性のことを指す。城の堀が敵の侵入を防ぐように、ビジネスにおける Moat は競合の参入を阻む構造的な障壁として機能する。ブランド力、ネットワーク効果、スイッチングコスト、独自データなどが代表的な Moat の例だ。

SoR（System of Record）とは

SoR は「記録のシステム」、つまりデータを入力・蓄積・管理するためのソフトウェアを指す。CRM、ERP、会計ソフトなど、業務データの正式な記録先として機能するシステムがこれにあたる。

2010 年代の SaaS ブーム期には、SoR に加えて以下の概念も議論されていた。

SoE（System of Engagement） — 顧客やユーザーとの接点を担うシステム
SoI（System of Insight） — データを分析し、示唆を得るためのシステム

これらは米国 VC 界隈では以前から知られたフレームワークだが、AI エージェントの登場によって、新たに SoA という概念が注目を集めている。

SoA（System of Action）とは

SoA は「行動のシステム」を意味する。従来のソフトウェアでは、データの分析結果をもとに人間が判断・実行していた。SoA では、AI エージェントがユーザーの意図を受け取り、自律的にデータ収集・処理・実行までを完結させる。

具体的には、

従来（SoR 中心）: ユーザーが UI を操作 → データ入力 → 分析結果を確認 → 人間が判断・行動
SoA 時代: ユーザーが意図を伝える → AI エージェントが複数システムを横断 → API や MCP 経由でデータ収集・処理 → 結果を自動で実行

この変化は単なる UI の改善ではなく、業務ソフトウェアの構造そのものの転換といえる。

ByteDance DeerFlow — オープンソースの SuperAgent 基盤でAIエージェントを自律運用する

Wed, 11 Mar 2026 00:00:00 +0000

ByteDance がオープンソースで公開した AI エージェント基盤「DeerFlow」（Deep Exploration and Efficient Research Flow）が注目を集めている。サブエージェントの自動振り分け、サンドボックスでのコード実行、長期メモリ、Claude Code 連携など、プロダクション運用を見据えた機能が揃っている。

DeerFlow とは

DeerFlow は、LangGraph / LangChain をベースに構築されたオープンソースの「SuperAgent ハーネス」。複雑なタスクをサブエージェントに分解し、メモリとサンドボックスを活用しながら自律的に処理する。

2026年2月27日に v2.0 がリリースされ、GitHub Trending で #1 を獲得。v2.0 は v1 とコードを共有しない完全な書き直しで、プロダクション環境でのデプロイに焦点を当てている。

主な機能

サブエージェントの自動振り分け

複雑なタスクを並列のサブエージェントワークフローに分解する。各サブエージェントは隔離されたコンテキストで動作し、スコープされたツールと終了条件を持つ。

サンドボックス実行

タスクはコンテナ化された Docker 環境で実行される。専用のファイルシステムが用意され、入力・作業・出力のディレクトリが分離されている。

/mnt/user-data/uploads/ ← 入力ファイル
/mnt/user-data/workspace/ ← 作業ディレクトリ
/mnt/user-data/outputs/ ← 最終成果物

3つの実行モードをサポート:

ローカル実行 — 開発用
Docker 実行 — 単一サーバーでのプロダクション
Kubernetes 実行 — マルチサーバー環境

スキルシステム

機能モジュールは Markdown ファイルとして提供される。リサーチ、レポート生成、スライド作成、Web ページ、画像/動画生成のスキルが組み込まれており、タスクの必要に応じてプログレッシブにロードされる。

長期メモリ

セッションをまたいだ永続的なプロファイルを構築できる。ユーザーの好み、ライティングスタイル、蓄積された知識をローカルに保存する。

コンテキスト管理

タスクの要約、中間結果のファイルシステムへのオフロード、長時間セッションでの圧縮された状態管理によって、コンテキストウィンドウを効率的に利用する。

セットアップ

Docker での起動（推奨）

1
2
3
4
5


git clone https://github.com/bytedance/deer-flow.git
cd deer-flow
make config # config.yaml を設定
make docker-init
make docker-start

http://localhost:2026 でアクセスできる。

Claude Code vs Codex：AI コーディングエージェント徹底比較 2026

Wed, 11 Mar 2026 00:00:00 +0000

AI コーディングエージェントの二大巨頭、Anthropic の Claude Code と OpenAI の Codex。どちらを使うべきか迷っている開発者は多いでしょう。Hesam 氏（@Hesamation）が数ヶ月間の実用比較を経て「Claude Code に戻った」という記事が話題になっています。本記事では、両ツールのベンチマーク・アーキテクチャ・実用上の使い分けを整理します。

ベンチマーク比較

SWE-bench Pro（ソフトウェアエンジニアリングタスク）

モデル	スコア
Claude Opus 4.6	59.0%
GPT-5.3-Codex	56.8%

複雑なソフトウェアエンジニアリングタスクでは Claude Opus 4.6 がリードしています。

Terminal-Bench 2.0（ターミナル操作タスク）

モデル	スコア
GPT-5.3-Codex	77.3%
Claude Opus 4.6	65.4%

一方、CLI 操作や CI/CD 関連のタスクでは Codex が強さを発揮します。

アーキテクチャの違い

コンテキストウィンドウ

Claude Code: 100万トークン（ベータ）
Codex: 40万トークン

Claude Code は 2.5 倍のコンテキストウィンドウを持ち、大規模なコードベースの横断的な分析に強みがあります。

実行速度

Codex: Cerebras WSE-3 で 1,000+ トークン/秒
Claude Code: 約 200 トークン/秒（標準推論）

速度面では Codex が圧倒的です。ただし、Claude Code はトークン消費量が 3.2〜4.2 倍多い傾向にあり、同じタスクでもより多くの推論を行っている可能性があります。

Claude Code vs OpenClaw — 「どっちを勉強すべき？」に対する責務ベースの選び方

Wed, 11 Mar 2026 00:00:00 +0000

AI コーディングエージェントの選択肢が増えるなか、「Claude Code と OpenClaw、どっちを勉強すべき？」という疑問を抱く人が増えている。AI駆動塾（@L_go_mrk）が両方を実際に触った上での比較記事を公開した。本記事では、この比較を起点に両ツールの位置づけを整理する。

そもそも何が違うのか

一言でまとめると、**Claude Code は「開発」、OpenClaw は「運用・自動化」**のためのツールだ。

観点	Claude Code	OpenClaw
開発元	Anthropic（プロプライエタリ）	Peter Steinberger（オープンソース）
主な用途	コーディング、PR レビュー、リファクタリング	日常タスク自動化、DevOps、定期ジョブ
インターフェース	ターミナル CLI	メッセージングアプリ（Telegram, Discord, Signal 等）
記憶	セッションごとにリセット（CLAUDE.md で補完）	永続メモリ（日記、TODO リスト、アイデンティティファイル）
料金	サブスクリプション（月額 $20〜）または API 従量課金	無料（接続する LLM API の料金のみ）
LLM	Claude モデル固定	Claude, DeepSeek, GPT 等を選択可能
セキュリティ	Anthropic が管理、安全ガードレール付き	ユーザー管理、システム権限を継承

Claude Code が強い領域

Claude Code は SWE-bench で約 80.8% のスコアを達成しており、複雑なコード変更やリファクタリングにおいて高い精度を発揮する。Extended Thinking による段階的な推論が、大規模な変更を安全に実行する鍵になっている。

強みをまとめると:

コード品質: Hooks による PostToolUse リンター自動実行、プリコミットチェック
PR ワークフロー: ブランチ作成→コミット→PR→レビューの一気通貫
エンタープライズ対応: Team / Enterprise プラン、Code Review 機能
安全性: 破壊的操作に対するガードレール

OpenClaw が強い領域

OpenClaw（愛称 “Molty”）は、常駐型の AI エージェントだ。ターミナルで起動して終了する Claude Code と異なり、バックグラウンドで動き続け、cron ジョブやウェブフックでタスクを実行する。

Claude Code のスキルを作るなら skill-creator プラグインを使おう

Wed, 11 Mar 2026 00:00:00 +0000

Anthropic が公開した「The Complete Guide to Building Skills for Claude」という 33 ページの PDF ガイドが話題になっています。このガイドをそのまま Claude Code のメモリに読み込ませてスキル構築に活用しようとする人もいますが、実は公式の skill-creator プラグインを使う方がはるかに効率的です。

skill-creator はガイドの内容をすべて反映しているだけでなく、テスト・最適化・トリガー精度改善といった仕組みも組み込まれています。PDF をメモリに入れるとコンテキストウィンドウを圧迫するリスクもあるため、新規スキル作成には skill-creator を導入するのがおすすめです。

Claude Code のスキルとは

スキルとは、Claude に特定のタスクの実行方法を教える 指示・スクリプト・リソースのフォルダ です。SKILL.md ファイルに YAML フロントマターと指示を記述するだけで作成できます。

Claude Code は 3 段階の情報ロードシステム（Progressive Disclosure）を採用しています。

起動時: インストール済みスキルの名前と説明文のみをシステムプロンプトに読み込む（スキルあたり約 50〜100 トークン）
判定時: ユーザーの入力に関連するスキルがあるかを判定
実行時: 該当スキルの全内容をロード

この仕組みにより、多数のスキルをインストールしてもコンテキストウィンドウを無駄に消費しません。

skill-creator プラグインのインストール

skill-creator は Anthropic 公式マーケットプレイスに含まれています。Claude Code 内で以下のコマンドを実行するだけでインストールできます。

1

/plugin install skill-creator@claude-plugins-official

インストール後、プラグインを有効化します。

1

/reload-plugins

なお、/plugin コマンドで Discover タブを開き、GUI からインストールすることも可能です。プラグイン機能を利用するには Claude Code バージョン 1.0.33 以上 が必要です（claude --version で確認できます）。

CLAUDE.md の設定を99%消したら逆にうまくいった話：AI への指示は「哲学」だけ残せ

Wed, 11 Mar 2026 00:00:00 +0000

Claude Code の設定ファイル CLAUDE.md に「こう書け」「これは禁止」「この順番で処理しろ」とルールを追加していったら 300行を超え、AI の出力品質がどんどん落ちていった——そんな経験を経て「99%消した。残したのは、哲学だけ。」という結論に至った話が X で話題になっている。

なぜルールを増やすと AI の性能が落ちるのか

コンテキストウィンドウの競合

LLM はコンテキストウィンドウ内のすべての情報を処理する。CLAUDE.md のルールが増えるほど、実際の作業に使える「注意力」が奪われる。コンテキストが埋まるにつれてパフォーマンスが低下するのは、LLM の根本的な特性だ。

指示の上限問題

IFScale ベンチマークの研究によると、フロンティアモデルは 150〜200個の指示 を超えたあたりから選択的注意のバイアスがピークに達し、それ以降は均一に失敗するパターンに収束する。Claude Code のシステムプロンプト自体がすでに約50個の指示を含んでいるため、ユーザーが使える枠は実質100〜150個。200行の詳細なルールを書いた時点で、すでに予算オーバーだ。

指示追従バイアス

LLM はプロンプトの 先頭と末尾 の指示に従いやすい傾向がある。中間に埋もれたルールは見落とされがちだ。ルールが増えるほど、重要な指示が中間に埋もれて無視されるリスクが高まる。

具体的に何が起こるか

例えば「見出しは H2 を必ず4つ使え」「セクションは5つ構成にしろ」というルールを設定したとする。すると AI は、本来3セクションで十分な内容でも無理やり5セクションに引き伸ばし、冗長な文章を生成してしまう。

ルールに 従うこと自体が目的化 し、最適な出力を考える余地がなくなる。これは人間の組織でも起こる現象だ。過剰なルールがかえって生産性を下げる。

「哲学だけ残す」アプローチ

細かいルールではなく方針を伝える

悪い例:

- 見出しは H2 を4つ使うこと
- 各セクションは200〜300文字
- コードブロックには必ず言語指定をつけること
- 箇条書きは最大5項目まで

良い例:

- 読者が最短で理解できる構成を優先する
- 冗長さよりも明確さを重視する

Anthropic 公式の推奨

Anthropic の公式ドキュメントでも、CLAUDE.md について以下のように推奨している:

肥大化した CLAUDE.md は、実際の指示を AI に無視させる原因になる
Claude がすでに正しくやっていることについては、わざわざルールを書かない
削除できるものは削除し、自動化できるものはフックに変換する

Progressive Disclosure パターン

すべての情報を CLAUDE.md に詰め込むのではなく、情報の見つけ方 を教える方法が効果的だ。

Google Gemini Embedding 2：テキスト・画像・動画・音声を統一ベクトル空間に埋め込むマルチモーダル埋め込みモデル

Wed, 11 Mar 2026 00:00:00 +0000

Google が 2026年3月に公開した Gemini Embedding 2 は、テキスト・画像・動画・音声・ドキュメントを同一のベクトル空間に埋め込める、初のネイティブマルチモーダル埋め込みモデルだ。RAG パイプラインやマルチモーダル検索を構築する開発者にとって注目すべきモデルとなっている。

主な特徴

ネイティブマルチモーダル対応

従来の埋め込みモデルはテキスト専用か、別モデルで画像を処理する必要があった。Gemini Embedding 2 は全モダリティを 3072次元の統一ベクトル空間 に直接埋め込む。これにより、テキストで検索して関連する画像や動画を取得するといったクロスモーダル検索が自然に実現できる。

対応モダリティと制限:

モダリティ	制限
テキスト	最大 8,192 トークン
画像	1リクエストあたり最大 6枚（PNG, JPEG）
動画	最大 120秒（MP4, MOV）
音声	ネイティブ対応（テキスト変換不要）

インターリーブ入力にも対応しており、1つのリクエストに画像とテキストを混在させて渡すことができる。

Matryoshka 表現学習（MRL）

Matryoshka Representation Learning（マトリョーシカ表現学習）により、重要な意味情報がベクトルの先頭次元に集約される設計になっている。デフォルトの 3,072次元から 1,536 や 768次元に切り詰めても、検索品質の大部分を維持できる。

Google の推奨次元数:

3,072次元：最高品質
1,536次元：高品質（コスト削減向け）
768次元：バランスの良い推奨値

768次元に切り詰めた場合でも、同サイズの固定次元モデルを上回る性能を発揮するとされている。

多言語対応と性能

100以上の言語をサポート
MTEB 多言語リーダーボードで 69.9 を記録しトップランク
MTEB コード検索でも 84.0 と高スコア

料金

プラン	料金
リアルタイム API	$0.20 / 100万トークン
バッチ API	$0.10 / 100万トークン（50% OFF）

OpenAI の text-embedding-3-small（$0.02/100万トークン）と比較すると高価だが、マルチモーダル対応を単一モデルで実現している点が差別化要因となる。

OpenAI Codex の SubAgent（Swarm）が変える AI コーディングの未来

Wed, 11 Mar 2026 00:00:00 +0000

OpenAI Codex に搭載された SubAgent（サブエージェント）機能が話題になっています。複数の AI エージェントを並列で動かし、複雑なコーディングタスクを群（Swarm）として処理できるこの機能について、技術的な詳細をまとめます。

SubAgent とは何か

Codex の SubAgent は、メインのエージェントが複数の専門化されたエージェントを並列でスポーン（生成）し、それぞれの結果を統合するワークフロー機能です。コードベース探索やマルチステップの機能実装など、並列処理が有効なタスクに特に威力を発揮します。

特筆すべきは、サブエージェントからさらにサブエージェントを生成できる（ネスト可能な）点です。これにより、複雑なタスクを再帰的に分解して処理できます。

ビルトインエージェント

Codex には3つのビルトインエージェントが用意されています。

エージェント	役割
`default`	汎用フォールバック
`worker`	実装・修正中心のタスク
`explorer`	コードベース探索中心のタスク

主要な設定パラメータ

1
2
3
4
5
6


# ~/.codex/agents/ または .codex/agents/ に TOML 形式で配置

[agents]
max_threads = 6 # 並行スレッド上限（デフォルト: 6）
max_depth = 1 # ネスト深度上限（デフォルト: 1）
job_max_runtime_seconds = 1800 # タイムアウト（デフォルト: 30分）

max_depth を増やすことで、サブエージェントからさらにサブエージェントを生成する多段ネストが可能になります。

OpenClaw エージェントでトレーディング戦略を自動バックテスト

Wed, 11 Mar 2026 00:00:00 +0000

OpenClaw エージェントを使って、TradingView の指標を自動スクレイピングし、Pine Script から Python に変換してバックテストまで全自動で実行する手法が話題になっています。

OpenClaw とは

OpenClaw は、オーストリアの開発者 Peter Steinberger 氏が 2025 年 11 月に Claude を使って構築したオープンソースの AI エージェントです。ローカルマシン上で動作し、自然言語の指示を受けてタスクを自律的に実行します。GitHub で 32 万以上のスターを獲得しており、2026 年初頭にはユーザー数が 200 万人を超えるなど急成長しています。

主な特徴:

マルチプラットフォーム対応: Mac / Windows / Linux で動作
メッセージ連携: WhatsApp、Telegram、Slack、Discord など複数チャネルに対応
スキルシステム: モジュラーなプラグイン（スキル）で機能を拡張可能
永続メモリ: コンテキストを記憶して継続的に動作

トレーディング戦略の自動バックテスト

今回話題になっているのは、OpenClaw エージェントを使ったトレーディング戦略の自動バックテストです。

処理の流れ

TradingView 指標の自動スクレイピング: TradingView から 50 以上のテクニカル指標を自動収集
Pine Script → Python 変換: TradingView 独自の Pine Script で書かれた指標を Python コードに自動変換
バックテスト実行: 変換した戦略を過去データで自動検証
結果のフィルタリング: 失敗した戦略を自動除外し、勝ちパターンを抽出
GitHub へのログ: テスト結果を自動で GitHub リポジトリに記録

設定を済ませれば、コードを一切書かずにこの一連のプロセスが自動で回り続けます。

OpenClaw のマークダウン駆動エージェント運用スタック：40日間の実践から学ぶ設計パターン

Wed, 11 Mar 2026 00:00:00 +0000

Google のシニア AI プロダクトマネージャー Shubham Saboo 氏が、OpenClaw エージェントを 40 日間運用した経験から導き出した「マークダウンファイル駆動のエージェント運用スタック」について紹介する。モデルを変えず、蓄積されたマークダウンファイルだけでエージェントが成長していくというアプローチだ。

コアコンセプト：マークダウンファイルが成長エンジン

このスタックの最大の特徴は、モデル自体は変わらないという点にある。エージェント間の違いは「蓄積されたマークダウンファイル」にある。データベースもオーケストレーションフレームワークもメッセージキューも不要で、ディスク上のマークダウンファイルがすべてのインテグレーション層として機能する。

3 層スタック構造

エージェントの設計は以下の 3 層で構成される：

1. Identity 層（アイデンティティ）

SOUL.md がセッション起動時に毎回読み込まれる。ここにはエージェントの人格、役割、原則、関係性が定義される。

1
2
3
4


# SOUL.md
- 役割: プロジェクトマネージャー
- 原則: 簡潔さを重視、事実ベースで判断
- 性格: Dwight Schrute 的な徹底さ

TV キャラクターの名前をエージェントに付けるのが Saboo 氏のテクニックだ。Claude の学習データにキャラクターの性格が含まれているため、「Dwight Schrute のエネルギーで」と伝えるだけで、徹底的で真剣な仕事ぶりが期待できる。

2. Operations 層（行動ルール）

AGENTS.md でセッション起動ルーティンとメモリ管理ルールを定義する。運用開始から約 1 週間後に作成するのが推奨される。

1
2
3
4


# AGENTS.md
- セッション開始時: MEMORY.md を読み込む
- タスク完了時: 日次ログに記録
- エラー発生時: 修正内容をメモリに追記

3. Knowledge 層（記憶・ログ）

MEMORY.md は約 2 週間の運用後に初期化する。日次ログをレビューし、繰り返し発生する修正パターンを恒久的なエントリとして蒸留していく。

OpenClawでX運用を自動化する鍵は「ナレッジ管理」にある

Wed, 11 Mar 2026 00:00:00 +0000

OpenClaw を使った X（旧 Twitter）運用で、1週間で79万インプレッション・フォロワー1,000人以上増加という成果報告が話題になっています。この記事では、その成果の背景にある「ナレッジ管理」と「投稿生成プロセス」の重要性について解説します。

OpenClaw × X運用の成果

@ichiaimarketer 氏が報告した成果:

約1週間で79万インプレッション
フォロワー1,000人以上増加

注目すべきは、この成果は OpenClaw のツール自体の力ではなく、使い方に依存しているという点です。

鍵は「ナレッジ管理」

AI に「思いつきで投稿させる」のではなく、蓄積された知識・経験をコンテキストとして与えることが重要です。

なぜナレッジ管理が重要か

コンテキストの質が出力の質を決める — LLM は与えられた情報から生成するため、ナレッジベースの質が投稿の質に直結する
一貫性のあるブランディング — 過去の投稿や知見を蓄積することで、アカウントとしての一貫した声が生まれる
専門性の反映 — 自分の専門知識をナレッジとして整理することで、AI が専門的な投稿を生成できる

OpenClaw でのナレッジ管理の実践

OpenClaw には Knowledge Management スキルが用意されており、メモリエントリを自動的に分類・整理できます。蓄積された知見は Research、Insight、Pattern などのフォルダに分類され、タイムスタンプ付きの Markdown ファイルとして保存されます。

また、OpenClaw の cron システムと組み合わせて定期的に同期することで、ナレッジベースを常に最新の状態に保てます。

この整理されたナレッジをスキルから参照することで、投稿生成時に適切なコンテキストを自動的に提供できます。

投稿生成プロセス

効果的な X 運用のための投稿生成プロセスは以下の流れです:

ナレッジの蓄積 — 日々の学びや知見をナレッジベースに追加
コンテキストの構築 — 投稿テーマに関連するナレッジを選択
AI による生成 — OpenClaw の bird スキルを使って投稿を生成
レビューと投稿 — 生成された内容を確認して投稿

OpenClaw の bird スキル

OpenClaw には bird というスキルが組み込まれており、X/Twitter の操作を CLI ベースで行えます:

Opik × OpenClaw — AI エージェントの動作を完全可視化するオブザーバビリティプラグイン

Wed, 11 Mar 2026 00:00:00 +0000

OpenClaw で AI エージェントを運用していると、「エージェントが内部で何をしているのか分からない」という課題に直面します。Comet チームが開発した opik-openclaw は、OpenClaw のエージェント動作をトレース・評価・監視できるオブザーバビリティプラグインです。AI の「ブラックボックス」を「ガラスボックス」に変えるツールとして注目されています。

Opik とは

Opik は、Comet が開発する Apache 2.0 ライセンスのオープンソース LLM オブザーバビリティプラットフォームです（GitHub で 18,000 以上のスター）。LLM アプリケーションのライフサイクル全体 — 開発・評価・本番監視 — をカバーする統合基盤として設計されています。

Opik の 3 つの柱

1. トレーシング（開発）

すべての LLM 呼び出しについて、プロンプト・レスポンス・メタデータ・コスト・レイテンシを詳細に記録します。1 日あたり 4,000 万以上のトレースを処理できるスケーラビリティを持ち、Prompt Playground でプロンプトの実験・比較も可能です。

2. 評価とテスト

LLM-as-a-judge によるハルシネーション検出、コンテキスト精度、回答の関連性といった自動評価メトリクスを提供します。データセットを定義して「良い回答とは何か」を基準化し、新バージョンのアプリを自動スコアリングできます。Pytest との統合により CI/CD パイプラインに評価を組み込むことも可能です。

1
2
3
4
5
6
7
8
9


from opik.evaluation.metrics import Hallucination

metric = Hallucination()
score = metric.score(
 input="フランスの首都は？",
 output="パリです。",
 context=["フランスの首都はパリである。"],
)
print(score) # HallucinationResult(score=0.0, reason="...")

3. 本番監視と最適化

opik-openclaw — OpenClaw の AIエージェント動作を可視化するオブザーバビリティツール

Wed, 11 Mar 2026 00:00:00 +0000

OpenClaw を使っていると「AI が裏で何をしているのか分からない」と感じることはありませんか？Comet が開発した opik-openclaw は、OpenClaw のエージェント動作をトレース・可視化するオープンソースプラグインです。AI を「ブラックボックス」から「ガラスボックス」に変えてくれます。

opik-openclaw とは

opik-openclaw は、Comet が開発する LLM オブザーバビリティプラットフォーム Opik（GitHub Star 18,000+）の OpenClaw 公式プラグインです。

OpenClaw のエージェントが実行するすべての操作を記録・可視化し、以下の情報をダッシュボードで確認できます。

LLM 呼び出し: 入出力ペア、トークン数、レイテンシ、コスト
ツール実行: どのツールが、いつ、どんな引数で呼ばれたか
エージェント委譲: サブエージェントへのタスク委譲の流れ
推論プロセス: 最初のメッセージから最終応答までの全会話フロー

セットアップ（3 コマンド）

1
2
3
4
5
6
7
8


# 1. プラグインをインストール
openclaw plugins install @opik/opik-openclaw

# 2. 認証情報を設定
openclaw opik configure

# 3. ゲートウェイを再起動
openclaw gateway restart

動作確認は以下のコマンドで行えます。

VS Code AI コーディングアシスタントのインストール数推移：GitHub Copilot の急落と競合の台頭

Wed, 11 Mar 2026 00:00:00 +0000

VS Code マーケットプレイスにおける AI コーディングアシスタントの日次インストール数を示すグラフが話題になっている。GitHub Copilot のインストール数が急激に落ち込む「崖」が鮮明に表れており、SaaS 事業者やプロダクトマネージャーにとって示唆に富む内容だ。

グラフが示すもの

「Daily Install Counts of AI Coding Assistants in Visual Studio Code」と題されたグラフには、以下の 3 つの AI コーディングアシスタントの日次インストール数（30日移動平均）が描かれている。

GitHub Copilot（オレンジ）：2021年末から着実に成長し、2025年後半には日次 150,000 インストール近くまで到達。しかし 2026年に入って急落し、現在は 60,000 前後まで落ち込んでいる
Claude Code（シアン）：2025年後半に登場し、直近で急速に伸長。日次 60,000 近くまで上昇
OpenAI Codex（イエロー）：同じく直近で伸びを見せているが、Claude Code よりやや控えめ

注目すべきは、GitHub Copilot のインストール数がピークから半分以下に急落している点だ。この「崖」は、競合の台頭と GitHub Copilot 自体の変化の両方が要因と考えられる。

急落の背景

GitHub Copilot の課金モデル変更

GitHub Copilot は 2024年12月に無料ティアを導入し、月 2,000 回のコード補完と 50 回のチャットリクエストという制限付きで提供を開始した。同時に、有料プランの価格体系も複雑化している。

Free：月 2,000 補完 / 50 チャット
Pro：$10/月
Pro+：$39/月
Business：$19/ユーザー/月
Enterprise：$39/ユーザー/月

無料ティアの導入は新規ユーザー獲得を狙った施策だが、既存の有料ユーザーが無料枠で十分と判断して解約するケースもあり得る。また、Microsoft は従来の IntelliCode を廃止し、AI 支援を Copilot に一本化する戦略を取っている。

Claude Code Review — エージェントチームが PR のバグを狩る新機能

Tue, 10 Mar 2026 00:00:00 +0000

Anthropic が Claude Code の新機能「Code Review」を発表した。PR が開かれると、複数のエージェントがチームとして並列にコードレビューを実行し、人間が見落としがちなバグを検出する。開発者の Boris Cherny 氏（@bcherny）は「数週間使って、自分では気づかなかった本物のバグを何度も見つけてくれた」と報告している。

仕組み

PR がオープンされると、Code Review は以下のステップを実行する:

エージェントチームの派遣 — 複数のエージェントが並列に動き、それぞれ異なるクラスの問題（ロジックエラー、セキュリティ脆弱性、コード品質など）を探す
検証フェーズ — 候補として検出された問題を実際のコード挙動と照合し、偽陽性をフィルタリングする
深刻度ランキング — 検出された問題を重要度順に並べる
レビューコメント投稿 — PR に対してサマリーコメント 1 件と、具体的な問題箇所へのインラインコメントを投稿する

レビューの深さは PR の規模と複雑さに応じてスケールする。大きく複雑な変更にはより多くのエージェントが投入される。

検出精度

Anthropic 社内でのテスト結果:

PR サイズ	指摘ありの割合	平均指摘数
大規模（1,000行以上）	84%	7.5件
小規模（50行未満）	31%	0.5件

特筆すべきは誤検出率が 1% 未満という点だ。エンジニアが「この指摘は間違い」と判定したケースがほとんどなく、検証フェーズによる偽陽性フィルタリングが効果的に機能していることを示している。

なぜ必要なのか

Cherny 氏によれば、Anthropic のエンジニア一人あたりのコード出力は 2026 年に入って 200% 増加した。AI コーディングエージェントによってコード生成が加速する一方で、レビューがボトルネックになっていた。人間のレビュアーが処理できる量には限界があり、AI が書いたコードも人間が書いたコードも、同じ品質基準でレビューする必要がある。

Code Review はこの問題に対する Anthropic 自身の解答だ。まず社内で使い、効果を確認した上で外部に公開している。

利用条件

対象プラン: Team / Enterprise（Research Preview）
料金: トークン使用量に基づく従量課金。PR サイズと複雑さに応じて平均 $15〜25
レビュー時間: 約 20 分
セットアップ: 管理者が GitHub App をインストールし、対象リポジトリを選択。開発者側の追加設定は不要

組織レベルでの月間支出上限、リポジトリ単位の有効化制御、レビュー受け入れ率の分析ダッシュボードも用意されている。

Claude Code Review — エージェントチームが PR のバグを狩る新機能

Tue, 10 Mar 2026 00:00:00 +0000

仕組み

PR がオープンされると、Code Review は以下のステップを実行する:

エージェントチームの派遣 — 複数のエージェントが並列に動き、それぞれ異なるクラスの問題（ロジックエラー、セキュリティ脆弱性、コード品質など）を探す
検証フェーズ — 候補として検出された問題を実際のコード挙動と照合し、偽陽性をフィルタリングする
深刻度ランキング — 検出された問題を重要度順に並べる
レビューコメント投稿 — PR に対してサマリーコメント 1 件と、具体的な問題箇所へのインラインコメントを投稿する

レビューの深さは PR の規模と複雑さに応じてスケールする。大きく複雑な変更にはより多くのエージェントが投入される。

検出精度

Anthropic 社内でのテスト結果:

PR サイズ	指摘ありの割合	平均指摘数
大規模（1,000行以上）	84%	7.5件
小規模（50行未満）	31%	0.5件

なぜ必要なのか

Code Review はこの問題に対する Anthropic 自身の解答だ。まず社内で使い、効果を確認した上で外部に公開している。

利用条件

対象プラン: Team / Enterprise（Research Preview）
料金: トークン使用量に基づく従量課金。PR サイズと複雑さに応じて平均 $15〜25
レビュー時間: 約 20 分
セットアップ: 管理者が GitHub App をインストールし、対象リポジトリを選択。開発者側の追加設定は不要

組織レベルでの月間支出上限、リポジトリ単位の有効化制御、レビュー受け入れ率の分析ダッシュボードも用意されている。

Claude Code Skills 構築完全ガイド — Anthropic 公式 33 ページの要点まとめ

Tue, 10 Mar 2026 00:00:00 +0000

Anthropic が公開した「The Complete Guide to Building Skills for Claude」は、Claude Code のスキル機能を本格的に活用するための 33 ページにわたる公式ガイドです。この記事では、ガイドの要点を日本語でまとめます。

Skills とは何か

Skills は、Claude に特定のタスクやワークフローを教えるための 再利用可能な指示セット です。フォルダにパッケージ化され、一度作れば Claude.ai、Claude Code、API のすべてで動作します。

従来のように毎回プロンプトで細かく指示する代わりに、Skills を使えば「一度教えて、何度でも使える」ようになります。

Skills のファイル構造

my-skill/
├── SKILL.md # メインの指示ファイル（必須）
├── scripts/ # 補助スクリプト
├── references/ # 参考資料
└── assets/ # アセットファイル

重要なルール:

メインファイルは必ず SKILL.md（大文字小文字を区別）
フォルダ名は kebab-case（例: notion-project-setup）
README.md は含めない

YAML フロントマターの設計

SKILL.md の冒頭に YAML フロントマターを記述します。ここがスキルの「顔」になります。

1
2
3
4


---
name: deploy-checker
description: "本番デプロイ前のチェックリストを実行する。デプロイや本番リリースの話題が出たときに使用する"
---

description には 何をするか と いつ使うか の 2 つを含めることが重要です。Claude はこのメタデータだけでスキルの使用タイミングを判断します。

Claude Code時代の仕様書の役割 — ゼロトピック #337 から考える仕様駆動開発

Tue, 10 Mar 2026 00:00:00 +0000

ゼロトピック（Zero Topic）の #337「Claude Code時代の仕様書の役割」が話題になっている。10X の矢本氏が、生成 AI が開発プロセスに与える影響と、仕様書の役割がどう変わるかを整理した回だ。

バイブコーディングの限界と仕様駆動開発

Claude Code のようなAIコーディングエージェントの登場で、コード生成速度は飛躍的に向上した。しかし「バイブコーディング」— AI に任せて探索的にコードを生成するアプローチ — には問題がある。

検証負債の蓄積: AI の生成速度が人間の理解・検証速度を上回る
意図不明なコード増殖: 内部構造を精査せず先に進み、誰も理解していない領域が広がる
デバッグ困難化: コードの意図が不明では根本原因の特定が難しい

こうした課題に対する解が 仕様駆動開発（Spec-Driven Development: SDD） だ。Thoughtworks Technology Radar Vol.32（2025年4月）で Trial に採用されたこの手法は、「仕様を先に定義し、その仕様に基づいて AI にコードを生成させる」という原則に立つ。

仕様書の役割の変化

従来の設計書は人間同士のコミュニケーションツールだった。AI との協働では「AI への指示書」としての側面が加わる。

SDD における仕様書の構成は、Kiro が提唱する3層モデルが分かりやすい:

ファイル	役割
`requirements.md`	ユーザーストーリーと受け入れ基準
`design.md`	アーキテクチャ、シーケンス、設計上の注意
`tasks.md`	実装計画とタスク分解

重要なポイントは、仕様は 「唯一の情報源（Single Source of Truth）」 として機能し、プロセス駆動はルールブック（プロセスルール）が別途担当するという区別だ。

Claude Code での実践

基礎レベル: CLAUDE.md + ステアリングファイル

CLAUDE.md に制約・規約・コンテキストを定義
.steering/ 配下に作業バッチフォルダを作成
要件定義書・設計書・タスクリストを生成・保存
タスクに沿ってコード生成・テスト実施

応用レベル: カスタムコマンドの活用

2026年1月に plansDirectory 設定が追加され、/plan モードで作成した計画書を Git 管理できるようになった。さらにカスタムコマンドを使えば、ドメイン知識を埋め込んだ独自のワークフローを構築できる。

freee MCP × Claude Code で確定申告の仕訳1,428件を20分で終わらせた話

Tue, 10 Mar 2026 00:00:00 +0000

minicoohei 氏（@minicoohei）が、freee の公式 MCP サーバーと Claude Code を組み合わせて確定申告の仕訳1,428件をわずか20分で完了させた事例を公開した。手作業なら4〜5時間かかる Amex のクレジットカード明細の仕訳登録を、AI が自動化した。

ワークフローの概要

Amex の取引明細（1,428件）を入力データとして用意 — 通常の手作業では1件ずつ勘定科目を判断して登録する必要がある
AI が70以上の分類ルールを自動生成 — 取引内容のパターンを分析し、勘定科目の振り分けルールを構築する
対話的なルール調整 — 人間との会話を通じてルールを精緻化する。税務リスクのある取引を事前に特定し、適切な処理方法を提案する
並列バッチ処理で一括登録 — freee API 経由で全件をエラーゼロで登録する

freee MCP とは

freee は公式の MCP サーバー（freee-mcp）を OSS として公開している。会計・人事労務・請求書・勤怠・販売の5領域にわたる API を、AI エージェントから操作可能にするインターフェースだ。

Claude Code や Claude Desktop から接続すると、「この請求書を発行して」「今月の経費を集計して」といった自然言語の指示で freee の業務を実行できる。

なぜ効果的なのか

従来の会計ソフトの自動仕訳機能は、事前に設定したルールに基づく単純なパターンマッチングだった。Claude Code を使うアプローチには以下の利点がある:

文脈理解による分類精度 — 取引先名や摘要の自然言語を理解して勘定科目を判断する。「AWS」なら通信費、「タクシー」なら旅費交通費、といった判断を人間と同等の精度で行える
対話による例外処理 — 判断に迷うケースを人間に確認し、その回答を以降のルールに反映する
バッチ処理の効率 — MCP 経由で freee API を直接操作するため、GUI での手作業が不要

実務での注意点

freee MCP を Claude Code と組み合わせる場合、いくつかの実務的な考慮点がある:

Karpathy の autoresearch — 寝ている間にAIが100回実験して朝にはモデルが賢くなっている世界

Tue, 10 Mar 2026 00:00:00 +0000

Andrej Karpathy が公開した autoresearch は、AI エージェントが自律的に ML 実験を繰り返すツールだ。寝ている間に AI が 100 回実験し、朝起きたらモデルが賢くなっている——そんな研究スタイルを 630 行の Python コードで実現する。

autoresearch とは

nanochat（軽量 LLM 学習コア）をシングル GPU・1 ファイルに凝縮し、AI エージェントが自律ループで学習コードを改善していく仕組み。

基本構造はシンプル:

人間が .md ファイル（プロンプト）を設計する
AI エージェントが .py（学習コード）を自律的に改善する

各実験は ちょうど 5 分間 のトレーニングで構成され、1 時間あたり約 12 回、一晩で約 100 回の実験が自動で回る。

人間: program.md を設計（研究の方針・制約を定義）
↓
AI エージェント: 学習コードを修正
↓
5分間のトレーニング実行
↓
結果を評価（validation loss）
↓
改善されていれば git commit → 次のイテレーションへ

技術的な特徴

630 行のミニマル設計

autoresearch の核心は「小さく始めて、エージェントに任せる」という哲学にある。

シングル GPU で完結（マルチ GPU 不要）
ニューラルネットワークのアーキテクチャ、オプティマイザ、ハイパーパラメータすべてを AI が調整
git feature ブランチ上で動作し、改善があれば自動コミット
MIT ライセンスで公開

「コードを書く」のではなく「プログラムをプログラムする」

Karpathy が強調するのは、研究者が Python ファイルを直接触るのではなく、Markdown でエージェントへの指示を設計するというパラダイムシフトだ。

MiroFish — 20歳の学生が10日間の Vibe Coding で作った AI 未来予測エンジンが GitHub Trending 1位に

Tue, 10 Mar 2026 00:00:00 +0000

20歳の中国の大学4年生・郭航江（Guo Hangjiang）氏が、わずか10日間の Vibe Coding で開発した OSS「MiroFish」が GitHub Trending で3日連続1位を獲得し、Star 数は約 11,000 を超えて急増中です。さらに、盛大グループ創業者の陳天橋氏がデモを見て24時間以内に3,000万元（約6.9億円）の即決投資を行ったと報じられています。

MiroFish とは

MiroFish は、マルチエージェント技術を活用した次世代の AI 予測エンジンです。ニュース・政策・金融データなどのテキストを投入すると、AI が数千の人格を持つエージェントを生成し、エージェント同士が相互作用することで未来の社会・市場の動きをシミュレートします。

公式の説明では「A Simple and Universal Swarm Intelligence Engine, Predicting Anything（簡潔で汎用的な群体知能エンジン、万物を予測）」とされています。

仕組み

MiroFish の動作は以下のステップで構成されます。

シード情報の抽出 — ニュース速報、政策草案、金融シグナルなどの現実世界のデータを取り込む
デジタルワールドの構築 — 取り込んだ情報から高忠実度な並行デジタル世界を自動構築
エージェントの生成 — 独立した人格、長期記憶、行動ロジックを持つ数千〜数万のエージェントを生成
社会進化シミュレーション — エージェント同士が自由に相互作用し、社会的進化を遂げる
変数注入と予測 — ユーザーが動的に変数を注入し、未来がどう展開するかの精密なシミュレーションを実行

想定される活用シナリオ

金融意思決定支援 — 市場動向の予測と投資判断
政策・世論予測 — 政策変更がもたらす社会的影響の分析
PR 危機シミュレーション — 企業の危機管理対応の事前検証
マーケティング戦略テスト — キャンペーン効果の事前予測
ストーリー・フィクション推演 — 物語の展開シミュレーション
学術研究支援 — 社会科学的仮説の検証

Vibe Coding で10日間

注目すべきは、MiroFish が Claude Code などの AI コーディングツールを活用した「Vibe Coding」で開発されたという点です。Vibe Coding とは、AI エージェントと対話しながら直感的にコードを生成していく開発手法で、従来の開発と比較して大幅な時間短縮が可能です。

OpenClaw × Claude Code セットアップガイド — AI エージェントチームを構築する2つのアプローチ

Tue, 10 Mar 2026 00:00:00 +0000

OpenClaw と Claude Code を組み合わせることで、AI エージェントチームの構築・管理を効率化できます。本記事では、2つの主要な連携アプローチとそのセットアップ方法を解説します。

アプローチ1: Claude Code のスキルで OpenClaw を管理する

Claude Code のスキル機能（.claude/skills/ に配置する Markdown ファイル）を使い、OpenClaw のエージェント作成・設定管理を標準化する方法です。

なぜスキルで管理するのか

複数の AI エージェントを運用していると、以下の問題が発生します:

モデルやコンテキストの違いによる設定の不統一
タイムゾーンフィールドの欠落、命名規則の不一致
スキーマ検証やコミットフックによる検証が存在しない

Claude Code スキルは「実行可能な基準」として機能し、モデルに依存せず一貫した手順を強制します。

セットアップ

cc-openclaw リポジトリを使います:

1
2
3


git clone https://github.com/rahulsub-be/cc-openclaw.git ~/cc-openclaw
cd ~/cc-openclaw
stow --no-folding -t ~/your-openclaw-home-repo .

ここで使っている stow は GNU Stow というシンボリックリンク管理ツールです。dotfiles 管理（.bashrc, .vimrc 等）でよく使われるもので、上記のコマンドは cc-openclaw リポジトリ内のファイル（.claude/skills/ 以下のスキル定義など）を、OpenClaw のホームリポジトリにシンボリックリンクとして配置します。コピーではなくリンクなので、cc-openclaw 側で git pull するだけでスキル定義が最新に更新されます。--no-folding オプションにより、ディレクトリ自体ではなくファイル単位でリンクが作成されます。

OpenClaw × Claude Code セットアップガイド — AI エージェントチームを構築する2つのアプローチ

Tue, 10 Mar 2026 00:00:00 +0000

アプローチ1: Claude Code のスキルで OpenClaw を管理する

Claude Code のスキル機能（.claude/skills/ に配置する Markdown ファイル）を使い、OpenClaw のエージェント作成・設定管理を標準化する方法です。

なぜスキルで管理するのか

複数の AI エージェントを運用していると、以下の問題が発生します:

モデルやコンテキストの違いによる設定の不統一
タイムゾーンフィールドの欠落、命名規則の不一致
スキーマ検証やコミットフックによる検証が存在しない

Claude Code スキルは「実行可能な基準」として機能し、モデルに依存せず一貫した手順を強制します。

セットアップ

cc-openclaw リポジトリを使います:

1
2
3


git clone https://github.com/rahulsub-be/cc-openclaw.git ~/cc-openclaw
cd ~/cc-openclaw
stow --no-folding -t ~/your-openclaw-home-repo .

OpenClaw × TikTok — AIエージェントでショート動画マーケティングを自動化する方法

Tue, 10 Mar 2026 00:00:00 +0000

OpenClaw をショート動画マーケティングの自動化マシンとして活用する事例が注目を集めています。AI エージェントが TikTok コンテンツの生成・投稿・分析・最適化をループで回し、数十万ビューとアプリダウンロードを達成するという仕組みです。

概要

Greg Isenberg が紹介した事例では、OpenClaw を「AI 従業員」として稼働させ、TikTok 向けのショート動画マーケティングを完全自動化しています。Oliver Henry 氏が構築した「Larry」と呼ばれるシステムは、コンテンツ生成からパフォーマンス分析、改善までを自律的に実行します。

Larry の仕組み

Larry は以下のループで動作するフルファネルのフィードバックエンジンです:

コンテンツ生成 — OpenClaw がスライドショー形式の TikTok コンテンツを自動作成
投稿準備 — API 直接投稿ではなく、ドラフトとして出力（アルゴリズムペナルティ回避のため、トレンドサウンドは手動追加）
パフォーマンス分析 — TikTok のアナリティクスデータを取得し、ビュー数・エンゲージメント・ダウンロード数を分析
最適化ループ — 分析結果をもとにフック（冒頭の引き）や CTA（行動喚起）を改善し、次のコンテンツに反映

TikTok アナリティクスがコンテンツ生成にフィードバックされ、アプリレベルの指標がファネル上部に戻るという循環構造が特徴です。

実績

1 投稿で 137,000 ビュー を達成（画像モデルとフックの最適化後）
別のユーザー（Ernesto Lopez 氏）は同様のアプローチで $70K MRR を報告
Oliver 氏はフルタイムの仕事を続けながら、このシステムで月数百ドルの MRR を生成

技術的なポイント

モデル選択は重要ではない

Oliver 氏は「Claude か OpenAI かの選択より、どう使いこなすかが重要。98% のユーザーはモデルの差分をほとんど感じない」と述べています。

OpenClaw スキルの利点

スキルはローカルで所有・編集可能
ホスティングやサブスクリプションのコストがゼロ
SaaS の代替としてのポテンシャル

Genviral の OpenClaw スキル

Genviral 社は OpenClaw 向けのソーシャルメディア自動化スキルをリリースしており、42 の API コマンドで TikTok、Instagram、YouTube、Facebook、Pinterest、LinkedIn の 6 プラットフォームに対応しています。

OpenClaw × 小紅書 — AI エージェントが SNS アカウントを完全自動運営する時代

Tue, 10 Mar 2026 00:00:00 +0000

中国の SNS「小紅書（Xiaohongshu / RED）」で、AI エージェントがアカウントを完全自動運営している事例が話題になっている。いち氏（@ichiaimarketer）が紹介したツイートによると、「虾薯（シャーシュー）」というアカウントは人間ではなく AI エージェントが運営しており、投稿の作成から公開、コメント返信、バズったコンテンツの分析・再現まで、すべて自動で行われている。

仕組み：2 つのスキルの連携

このシステムは、OpenClaw のスキル（プラグイン）として公開されている 2 つの GitHub プロジェクトで構成されている。

Auto-Redbook-Skills（コンテンツ制作）

comeonzhj/Auto-Redbook-Skills — AI による記事作成と画像生成、自動公開を担当する。

AI がテーマに沿った投稿文を自動生成
8 種類のテンプレートからカバー画像を自動レンダリング
小紅書への自動公開

xiaohongshu-ops-skill（運営オペレーション）

Xiangyu-CAS/xiaohongshu-ops-skill — アカウントの日常運営を自動化する。

投稿の自動公開スケジューリング
コメントへの自動返信（アカウントのペルソナに合わせた口調で）
バズった投稿の分析と複製（「爆款復刻」）
アカウントごとのキャラクター設定

この 2 つが連携することで、AI が記事を書き → カバー画像を生成 → 自動公開 → コメントに返信 → バズコンテンツを分析して再現という完全自動のループが実現している。

OpenClaw エコシステムの広がり

OpenClaw は 2026 年に入って爆発的に成長し、GitHub のスター数は 2,400 万を超えた。個人の端末上で動作する AI エージェントで、WhatsApp・Telegram・Discord などのチャットアプリを通じて操作できる。

小紅書以外にも、TikTok や各種 SNS プラットフォーム向けのスキルが続々と公開されており、「一人で複数アカウントをマトリクス運営する」ことが技術的に可能になっている。

コンプライアンス上の懸念

技術的には可能だが、プラットフォームの利用規約やコンプライアンスの問題は無視できない。

ローカルQwenに個人知識を覚えさせたい — ファインチューニング vs RAG

Tue, 10 Mar 2026 00:00:00 +0000

ローカルで Ollama + Qwen を動かしている Mac Studio（M3 Ultra / 96GB）に、NAS 上の PDF やテキストなどのドキュメントを学習させて「個人の知識ベース」として活用したい——そんなとき、ファインチューニングと RAG のどちらを選ぶべきかを整理する。

やりたいこと

NAS に蓄積された個人ドキュメント（PDF、テキスト等）の知識を Qwen に覚えさせたい
自分の PC を使った活動に関する知識を、AI が把握している状態にしたい

選択肢1: ファインチューニング（QLoRA）

モデル自体の重みを更新し、知識を「記憶」させるアプローチ。

Mac Studio での実現可能性

M3 Ultra / 96GB 統合メモリなら、QLoRA でのファインチューニングは技術的に可能。

手法	必要メモリ目安（7B）	ツール
QLoRA (4bit)	6-8 GB	Unsloth, LLaMA-Factory, MLX
LoRA (16bit)	14-16 GB	LLaMA-Factory, PEFT
フル FT	60+ GB	非現実的

Apple Silicon では MLX ベースが最もパフォーマンスが良い。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# MLX での QLoRA 実行例
pip install mlx-lm

mlx_lm.lora \
 --model Qwen/Qwen2.5-Coder-14B-Instruct \
 --data ./training_data \
 --train \
 --batch-size 1 \
 --lora-layers 16 \
 --iters 1000

ファインチューニングの課題

最大のボトルネックはデータ準備。NAS の生ファイルはそのまま学習データにはならず、instruction 形式への変換が必要になる。

「研究コミュニティをまるごとエミュレートせよ」— Karpathy が示す AI エージェント協調の未来

Mon, 09 Mar 2026 00:00:00 +0000

Andrej Karpathy が autoresearch を公開した直後、さらに踏み込んだビジョンを示した。「次のステップは、エージェント同士が非同期かつ大規模に協調する仕組みだ」— 単一エージェントの能力向上ではなく、エージェント群の協調システム設計こそが本質だという主張だ。

「一人の博士課程ではなく、研究コミュニティを」

The goal is not to emulate a single PhD student, it’s to emulate a research community of them. （目標は一人の博士課程の学生をエミュレートすることではない。研究コミュニティをまるごとエミュレートすることだ。）

現在の autoresearch はコミットを同期的に一本のスレッドで積み上げていく設計だ。だが Karpathy が構想するのは、リポジトリを「種」として無数のエージェントがそこから枝分かれし、異なる研究方向に並列で進んでいく世界だ。SETI@home のような分散コンピューティングモデルを研究に適用するイメージだと言える。

技術的な課題

この構想が実現するには、いくつかのハードルがある:

分散タスクシャーディング — 実験をどう分割して割り当てるか
結果の重複排除 — 同じ仮説を複数エージェントが試す無駄をどう防ぐか
クロスエージェントメモリ — あるエージェントの発見を他のエージェントが活用できる仕組み
Git の限界 — 「一本の master ブランチ + 一時的な PR」という既存の Git モデルでは、エージェントが数千のコミットを並列に管理する構造に対応しきれない

Karpathy 自身も、Discussions や PR を使ったエージェント間の知見共有を軽量にプロトタイピングしたと述べている。

「一つを賢くする」から「場の設計」へ

IT navi 氏（@itnavi2022）は、この動きを端的にこう要約している:

AI が一人の研究者を代替するのではなく、無数のエージェントが並列に仮説を試し、成果や失敗を持ち寄りながら、ひとつの研究コミュニティのように知を前進させる未来だ。問題は、一つのエージェントを賢くすることではなく、無数のエージェントが枝分かれしながら知見を蓄積する場をどう設計するかに移りつつある。

これは AI エージェント開発における重要なパラダイムシフトだ。これまでの議論は「いかにモデルを賢くするか」「いかにプロンプトを最適化するか」に集中していた。だが autoresearch が示す方向は、個のエージェントの能力向上よりも、エージェント群の協調システム設計に重心が移りつつあるということだ。

Karpathy の言葉を借りれば、エージェントの「知性、注意力、粘り強さがボトルネックでなくなった」とき、既存の開発抽象（Git、CI/CD、コードレビュー）にますます圧力がかかる。

「研究コミュニティをまるごとエミュレートせよ」— Karpathy が示す AI エージェント協調の未来

Mon, 09 Mar 2026 00:00:00 +0000

「一人の博士課程ではなく、研究コミュニティを」

The goal is not to emulate a single PhD student, it’s to emulate a research community of them. （目標は一人の博士課程の学生をエミュレートすることではない。研究コミュニティをまるごとエミュレートすることだ。）

技術的な課題

この構想が実現するには、いくつかのハードルがある:

分散タスクシャーディング — 実験をどう分割して割り当てるか
結果の重複排除 — 同じ仮説を複数エージェントが試す無駄をどう防ぐか
クロスエージェントメモリ — あるエージェントの発見を他のエージェントが活用できる仕組み
Git の限界 — 「一本の master ブランチ + 一時的な PR」という既存の Git モデルでは、エージェントが数千のコミットを並列に管理する構造に対応しきれない

Karpathy 自身も、Discussions や PR を使ったエージェント間の知見共有を軽量にプロトタイピングしたと述べている。

「一つを賢くする」から「場の設計」へ

IT navi 氏（@itnavi2022）は、この動きを端的にこう要約している:

AI が一人の研究者を代替するのではなく、無数のエージェントが並列に仮説を試し、成果や失敗を持ち寄りながら、ひとつの研究コミュニティのように知を前進させる未来だ。問題は、一つのエージェントを賢くすることではなく、無数のエージェントが枝分かれしながら知見を蓄積する場をどう設計するかに移りつつある。

AGENTS.md は詳しすぎると逆効果 — ETH Zurich の138リポジトリ研究が示す「書かない」原則

Mon, 09 Mar 2026 00:00:00 +0000

AI コーディングエージェントの設定ファイル（AGENTS.md、CLAUDE.md など）は「詳しく書くほど良い」と思われがちだ。しかし ETH Zurich の研究チームが138リポジトリ・5,694プルリクエストを対象に行った調査で、詳細すぎるコンテキストファイルはむしろ性能を下げることが実証された。

研究の概要

ETH Zurich の Gloaguen、Mündler、Müller、Raychev、Vechev らが2026年2月に発表した論文で、AGENTS.md ファイルが AI コーディングエージェントの性能に与える影響を大規模に検証した。

対象: 138リポジトリ、5,694プルリクエスト
検証: LLM 生成ファイルと人間が書いたファイルの両方を比較

衝撃的な結果

自動生成されたコンテキストファイルは害になる

成功率が約3%低下
推論コストが20%以上増加
エージェントは推論トークンの14〜22%をドキュメント処理に消費

人間が書いても効果は限定的

改善はわずか**4%**にとどまる
コストの増加に見合わない

なぜ詳細な指示が逆効果になるのか

AI エージェントは「従順すぎる」

エージェントはコンテキストファイルの指示を律儀に守る。そのため、不要な制約が含まれていると逆にタスクが難しくなる。「良かれと思って書いた指示」が足を引っ張る。

ディレクトリツリーやコードベース概要は不要

エージェントはファイル構造を自力で発見するのが得意だ。手動でディレクトリツリーを記述しても、トークンを消費するだけでナビゲーション速度は改善しない。

強いモデルほど追加コンテキストが邪魔になる

GPT-5.2 のような強力なモデルは、ライブラリや慣例のパラメトリック知識を既に持っている。追加コンテキストは冗長なノイズになるだけだ。

効果があるのは「非自明なツール指定」

研究で唯一、劇的な効果が確認されたのはプロジェクト固有のツール指定だ：

pip の代わりに uv を使う
npm の代わりに bun を使う

例えば uv を明示した場合、160倍多く使われたという結果が出ている。エージェントが自力では推測できない「非自明な選択」だけを書くのが正解だ。

推奨される6つの原則

コード内で発見可能な情報は除外 — エージェントが自力で見つけられるものは書かない
否定形ではなく肯定形で指示 — 「〜するな」ではなく「〜せよ」
決定論的チェックと組み合わせる — linter やテストで検証可能なルールを設定
想定ではなく実際の失敗から反復 — 問題が起きてから追記する
重要情報を最初に配置 — トークン処理の優先順位を考慮
30行以下を目指す — プロチームは60行以下、推奨は300行以下

実践的な AGENTS.md の書き方

悪い例（よくある過剰な記述）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# プロジェクト概要
このプロジェクトは React + TypeScript で構築された...

# ディレクトリ構造
src/
├── components/
├── hooks/
├── utils/
└── pages/

# コーディング規約
- 変数名はキャメルケースを使用する
- コンポーネントはアロー関数で定義する
- インポートは以下の順序で記述する...
（以下100行続く）

良い例（非自明な指定のみ）

1
2
3
4
5
6
7
8


# ツール
- パッケージマネージャ: bun（npm/yarn ではなく）
- テストランナー: vitest
- フォーマッタ: biome（prettier ではなく）

# プロジェクト固有のルール
- API クライアントは src/lib/api.ts の共通関数を使う
- 環境変数は .env.local から読み込む（.env は使わない）

最良の AGENTS.md は不要なものである

研究が示す最も重要な結論は、AGENTS.md の改善に時間を費やすより、コードベース自体を改善すべきということだ：

AI Agent に品質を担保させる — QA 手法の実践ガイド

Mon, 09 Mar 2026 00:00:00 +0000

Claude Code や Cursor、Devin といった AI コーディングエージェントの導入が進むなか、「品質をどう担保するか」が最大の課題になっている。栗田氏（@hikarine3）が公開した実践ガイドから、要点を紹介する。

Sonar の調査によれば、開発者の 96% が AI 生成コードを完全には信頼していないにもかかわらず、実際に検証しているのは 48% に過ぎない。この「検証ギャップ」が AI 開発における最大のリスクだ。

1. 設定ファイルにルールを書く

CLAUDE.md や .cursorrules 等の設定ファイルに、最低限 3 つのルールを書くだけで事故を大幅に減らせる。

ルール	防げる事故
テスト結果を「○件中○件が正常」形式で報告	0 件検出の見落とし
影響範囲を確認	1 ファイル修正で他が壊れる
ファイル削除・本番デプロイ・DB 操作は承認必須	取り返しのつかないミス

設定ファイルは 50 行以内 を推奨。IFScale の研究では、指示が長すぎると AI が先頭と末尾だけに従う傾向がある。詳細は別ファイルへの参照（ポインタ設計）で対応する。

2. リスクレベルで使い分ける

すべてのプロジェクトに同じ品質基準を適用する必要はない。

レベル	対象	テスト深度
ラフ	静的サイト、ブログ	目視確認
標準	Web アプリ（ユーザーデータあり）	回帰テスト
厳密	金融・決済・認証・個人情報	境界値・異常系テスト

3. AI にテスト設計もさせる

従来のように 12 項目のチェックリストを人間が作るのではなく、「この変更の回帰テストをして。検出件数も報告して」と指示するだけで、AI がテストケースの設計・実行・報告まで行える。

4. AI のテストが「嘘」になる 10 パターン

AI エージェントが出す「全件正常です」を鵜呑みにしてはいけない。代表的な落とし穴:

AI Agent に品質を担保させる — QA 手法の実践ガイド

Mon, 09 Mar 2026 00:00:00 +0000

1. 設定ファイルにルールを書く

CLAUDE.md や .cursorrules 等の設定ファイルに、最低限 3 つのルールを書くだけで事故を大幅に減らせる。

ルール	防げる事故
テスト結果を「○件中○件が正常」形式で報告	0 件検出の見落とし
影響範囲を確認	1 ファイル修正で他が壊れる
ファイル削除・本番デプロイ・DB 操作は承認必須	取り返しのつかないミス

2. リスクレベルで使い分ける

すべてのプロジェクトに同じ品質基準を適用する必要はない。

レベル	対象	テスト深度
ラフ	静的サイト、ブログ	目視確認
標準	Web アプリ（ユーザーデータあり）	回帰テスト
厳密	金融・決済・認証・個人情報	境界値・異常系テスト

3. AI にテスト設計もさせる

4. AI のテストが「嘘」になる 10 パターン

AI エージェントが出す「全件正常です」を鵜呑みにしてはいけない。代表的な落とし穴:

Claude Code Security — AI がコードベースの脆弱性を発見・修正提案する新機能

Mon, 09 Mar 2026 00:00:00 +0000

Anthropic が Claude Code Security を限定リサーチプレビューとして公開しました。AI がコードベース全体をスキャンして脆弱性を検出し、修正パッチまで提案してくれる機能です。

Claude Code Security とは

従来の静的分析ツール（SAST）はルールベースでパターンマッチングを行うため、ビジネスロジックの欠陥やアクセス制御の不備など、文脈依存の脆弱性を見落としがちでした。

Claude Code Security は、人間のセキュリティ研究者のようにコードを「理解」するアプローチを採用しています。

コンポーネント間の相互作用を把握する
アプリケーション全体のデータフローを追跡する
ルールベースツールでは検出困難な脆弱性を発見する

主な特徴

多段階検証プロセス

検出した脆弱性は多段階の検証プロセスにかけられ、誤検知（false positive）がフィルタリングされます。各脆弱性には重大度評価と信頼度スコアが付与されます。

ヒューマン・イン・ザ・ループ

修正パッチは自動適用されません。Claude Code Security は問題の特定と解決策の提案を行い、最終的な判断は開発者が行います。

実績

Anthropic のレッドチーム活動では、Claude Opus 4.6 を使用して本番環境のオープンソースプロジェクトから 500 以上の脆弱性 を発見しました。これらは数十年にわたり専門家のレビューを経ても検出されなかったバグです。

利用方法

プラン	利用可否
Enterprise	即時利用可能
Team	即時利用可能
オープンソースメンテナー	無料で迅速なアクセスを提供（申請制）

詳細は Anthropic 公式の Claude Code Security ページを参照してください。

従来のツールとの違い

従来の SAST ツールは既知のパターンを検索する仕組みのため、新しいタイプの脆弱性や複雑なロジックの欠陥には対応しきれませんでした。Claude Code Security は LLM の推論能力を活用して、コードの意味を理解した上で脆弱性を検出するという点で、セキュリティスキャンの新しいアプローチといえます。

まとめ

Claude Code Security は「脆弱性は多いが対応する人員が少ない」というセキュリティチームの課題に対し、AI による自動検出と修正提案で支援するツールです。現時点では限定リサーチプレビューですが、今後のセキュリティ開発ワークフローに大きな影響を与える可能性があります。

Claude Code でツール実行前にセキュリティリスクをパーセンテージ表示させる CLAUDE.md 設定

Mon, 09 Mar 2026 00:00:00 +0000

Claude Code でツール実行の許可を求められるたびに、セキュリティリスクをパーセンテージで表示させる CLAUDE.md の設定が話題になっています。「なんかやばそうだけど…まあいいか」で Yes を連打してしまう問題への対策です。

背景

Claude Code はファイル操作やシェルコマンドの実行時にユーザーの許可を求めますが、表示される内容だけでは何がどの程度危険なのか判断しにくいことがあります。特に初心者は、よく分からないまま Yes を連打してしまいがちです。

CLAUDE.md に追加する設定

プロジェクトのルートディレクトリにある CLAUDE.md に以下の内容を追加します:

1
2
3
4
5
6
7
8


## ツール実行時の許可ルール

- ツール実行（Bash、ファイル操作など）の許可を求めるときは、必ず日本語で説明・確認を行うこと
- 許可を求める際、以下のセキュリティリスクをパーセンテージ(%)で提示すること
 - パスワードや秘密鍵が外に漏れる可能性
 - 外部サーバーにデータが送られる可能性
 - 悪意あるコードが勝手に動く可能性
 - PCの設定が書き換わる可能性

表示イメージ

この設定を入れると、ツール実行の確認時に以下のようなリスク評価が表示されるようになります:

・パスワードが外に漏れる可能性: 0%
・外部サーバーにデータが送られる可能性: 0%
・悪意あるコードが動く可能性: 5%
・PCの設定が書き換わる可能性: 80%

これにより、各操作のリスクを具体的な数値で把握した上で、許可するかどうかを判断できるようになります。

Claude Codeですべての日常業務を爆速化する — コーディング以外の活用術

Mon, 09 Mar 2026 00:00:00 +0000

Claude Code はコーディング専用ツールと思われがちだが、実はコーディング以外の日常業務を半自動化する強力なツールとしても活用できる。みのるん氏（@minorun365）の Qiita 記事から、その実践例を紹介する。

AI は「自動化ツール」ではなく「優秀な同僚」

Claude Code を使う上で重要なマインドセットは、AI を単なる自動化ツールではなく「一緒に仕事できる優秀な同僚」として捉えること。どんな作業でも「この作業、Claude Code に任せられないか？」と必ず考える習慣が、業務効率を大きく変える。

また「AI 活用＝やっつけ品質」という認識はもう過去の話で、適切に指示を出せば高品質なアウトプットが得られる。

プチ仕様駆動開発

Claude Code との作業では、以下の 4 つのドキュメントで「プチ仕様駆動開発」を行うのが効果的。

ドキュメント	用途
`PLAN.md`	音声入力で計画を記録
`SPEC.md`	仕様の壁打ち
`TODO.md`	タスク管理
`KNOWLEDGE.md`	学びとナレッジの蓄積

音声入力（Aqua Voice 等）で大まかな計画を PLAN.md に吹き込み、Claude Code に仕様化してもらうフローが実用的。

実践例: 経費精算を 5 分で終わらせる

MoneyForward の CSV を Claude Code に渡して、以下を自動化する:

CSV を解析して取引を分類
Gmail から領収書を自動検索
勘定科目を自動マッピング
Markdown 形式で出力

手作業なら 30 分以上かかる経費精算が、5 分で完了する。

実践例: メール監視とリマインド

放置しがちなメールの監視を自動化する構成:

EventBridge（定時起動）
→ AgentCore Runtime
→ Gmail API でメール抽出
→ Slack に通知

重要なメールを見落とすリスクを、システムで解消する。

Claudeのデザインが急に良くなった理由 ― frontend-design スキルと「一般的」から離れるプロンプト

Mon, 09 Mar 2026 00:00:00 +0000

Claude Code で生成される UI デザインの品質が急に向上したと話題になっています。その理由は「画像学習」の強化ではなく、「一般的（on distribution）」なデザインから意図的に離れるプロンプト設計にありました。

AIスロップ問題とは

AI が生成するフロントエンドデザインには「AIスロップ（AI slop）」と呼ばれる品質問題があります。特に指示を与えずに UI を生成させると、AI は確率分布の中心付近からサンプリングするため、どこかで見たような「いかにもAIが作った」デザインに収束してしまいます。

具体的には以下のような特徴が見られます:

過度にグラデーションやシャドウを多用する
汎用的すぎるカラーパレット
差別化のないカードレイアウト
どのサイトでも見るような Hero セクション

frontend-design スキルの登場

Anthropic は Claude Code 向けに frontend-design という公式スキルをリリースしました。このスキルの核心は、Claude に対して**「一般的な出力に収束しないように」**と明示的に指示することです。

スキルの中には以下のような指針が含まれています:

確率分布の中心（もっとも一般的なデザインパターン）に寄らないこと
AIスロップ的な美学を避けること
個性のあるデザインを生成すること

なぜプロンプトで解決できるのか

Claude は十分なデザイン知識を持っています。問題は、指示がないと「安全な」中間値に落ち着いてしまうことでした。frontend-design スキルは、この傾向を明示的に打ち消すプロンプトを提供することで、Claude が持つ本来のデザイン能力を引き出しています。

これは画像生成 AI における「ネガティブプロンプト」に近い考え方です。生成したいものを指定するだけでなく、避けたいもの（一般的すぎるデザイン）を指定することで、出力品質が大きく向上します。

実践のポイント

自分のプロジェクトでも同様のアプローチを取ることができます:

「一般的にしないで」と明示する ― デザイン生成時に「よくあるパターンを避けて」と指示する
具体的なリファレンスを与える ― 参考にしたいデザインの方向性を具体的に伝える
frontend-design スキルを活用する ― Claude Code を使っているなら、このスキルを有効にする

1
2


# Claude Code でスキルをインストール
npx skills add anthropics/claude-code

Claude Code 内では /skills コマンドでインストール済みスキルの一覧を確認できます。

GSD — AI コーディングエージェントを「本当に使えるレベル」にするプロジェクト管理システム

Mon, 09 Mar 2026 00:00:00 +0000

AI コーディングエージェントで「ランディングページを作って」くらいなら動く。しかし、複数ファイル・複数サブシステムが絡む本格的なプロジェクトになると、エージェントはコヒーレンスを失い、前に作ったものを忘れ、壊れたコードを量産し始める。GSD はこの問題を構造的に解決するシステムだ。

GSD とは

GSD（Get Stuff Done）は、大規模・マルチセッションのプロジェクトを AI コーディングエージェントで完遂するためのシステムだ。デモ向けのおもちゃではなく、多数のファイルと複数のサブシステムが連携する実務レベルのプロジェクトを対象としている。

GSD が解決する問題は明確だ：

エージェントは時間とともにコヒーレンスを失う
3タスク前に作ったものを忘れる
ファイルは存在するが実際には動かないコードを生成する
毎ターン、プロジェクト構造の再読み込みにトークンを浪費する
中断後の再開には人間が全てを再説明する必要がある
何かが壊れたとき、クリーンなロールバック手段がない

3層の階層構造：Milestone → Slice → Task

GSD はすべてのスコープを3つのレベルに分解する。

Milestone（マイルストーン）

出荷可能なバージョン。プロジェクトの大きな単位。

Slice（スライス）

独立してデモ可能な垂直的な機能単位。「データベース層を実装する」（水平的）ではなく、「ユーザーがサインアップしてログインできる」（垂直的）という形で切る。

各スライスにはデモ文がある：「これが完了すると、ユーザーは _____ できる」。この空白を人間が観察可能な行動で埋められなければ、スコープの切り方が間違っている。

Task（タスク）

コンテキストウィンドウ1つ分の作業単位。1タスクが1エージェントセッションに収まらなければ、それは2タスクだ。これは鉄則であり、違反するとエージェントがコヒーレンスを失い始める — 長時間の作業で初期の判断がコンパクション（圧縮）され、コンテキストが古いツールコールで汚染され、推論品質が劣化する。

Boundary Maps — 実装前のインターフェース思考

GSD で最もインパクトのある計画機能がこれだ。

マイルストーンの計画時に、各スライスは何を生産し、上流のスライスから何を消費するかを具体的に宣言する。曖昧にではなく、関数名・型名・インターフェース・エンドポイントを名前付きで。

S01 → S02
Produces:
types.ts → User, Session, AuthToken (interfaces)
auth.ts → generateToken(), verifyToken(), refreshToken()
Consumes: nothing (leaf node)
S02 → S03
Produces:
api/auth/login.ts → POST handler
middleware.ts → authMiddleware()
Consumes from S01:
auth.ts → generateToken(), verifyToken()

これにより「スライス3が必要とする関数をスライス1がエクスポートしていない」という問題が発生しない。契約が明示的で、検証可能になる。

Harness Engineering ベストプラクティス 2026 — AI コーディングエージェントを安定稼働させる設計術

Mon, 09 Mar 2026 00:00:00 +0000

Claude Code や Codex といった AI コーディングエージェントを現場に投入する開発者が増えるなか、「ハーネスエンジニアリング」という新しい実践領域が注目を集めている。逆瀬川氏（@gyakuse）が公開したまとめ記事から、要点を紹介する。

そもそも「ハーネス」とは何か

「ハーネス（harness）」とは、もともと馬具の意味だ。馬の力を人間が制御して活かすための装具一式 — 手綱、鞍、轡（くつわ）などを指す。馬がどれだけ優秀でも、ハーネスなしでは暴走するだけで仕事にならない。

ソフトウェアの世界では「テストハーネス」という用語がすでにある。テスト対象のコードを「つなぎ止めて」、入力を与え、出力を検証する枠組みのことだ。テスト対象そのものではなく、テスト対象を正しく動かすための外側の仕組みを指す。

AI コーディングエージェントにおける「ハーネス」もこれと同じ発想だ。AI エージェント（= 馬）は強力だが、そのままでは暴走する。古いドキュメントを信じてしまう、リンターのルールを勝手に緩和する、前のセッションで何をしたか忘れる。エージェントを制御し、安定した成果を引き出すための外側の仕組み全体がハーネスであり、それを設計・構築する技術がハーネスエンジニアリングだ。

具体的にハーネスを構成する要素は、大きく 3 つの層に分けられる:

入力層 — エージェントに何を読ませ、何を読ませないかを制御する（AGENTS.md の設計、リポジトリの衛生管理、セッション間の状態引き継ぎ）
実行制御層 — エージェントの作業中にリアルタイムで品質を強制する（リンター・フォーマッターの自動実行、計画と実行の分離）
検証層 — エージェントの出力が正しいことを確認する（E2E テスト、プリコミットチェック）

核心的な洞察は「ハーネスがモデルより重要」という点だ。同じモデルでもハーネスを改善すれば出力品質が劇的に向上する。開発者の責任は「正しいコードを書く」から「エージェントが確実に正しいコードを生産する環境を設計する」へとシフトしている。

7 つの主要トピック

1. リポジトリ衛生〈入力層〉

「衛生（hygiene）」は、ソフトウェア開発で「不要物や汚染を取り除き、健全な状態を保つ」という意味で使われる慣用表現だ（「コードハイジーン」「ブランチハイジーン」なども同様）。ここでは、リポジトリ内に古くなったドキュメントや不正確な情報が溜まらないよう清潔に保つことを指す。人間なら「このメモ、古そうだな」と判断できるが、エージェントは 3 ヶ月前のメモも最新のコードも同じ「事実」として読んでしまう。だから情報の鮮度管理が重要になる。

実行可能なアーティファクト（コード、テスト、設定）を優先する
説明的ドキュメントは腐敗しやすいため最小化する
ADR（Architecture Decision Records）で決定履歴を保全する
テストはドキュメントより腐敗に強い

最大の敵は「説明的ドキュメントの腐敗」だ。エージェントは「3 ヶ月前のメモ」と「現在の真実」を区別できないため、古い情報が存在するだけで性能が低下する。ハーネスの入力層として、エージェントが読む情報の鮮度と正確性を保つことが最初のステップになる。

2. 決定論的ツールで品質を強制する〈実行制御層〉

「決定論的（deterministic）」とは、同じ入力に対して毎回必ず同じ結果を返すという意味だ。リンターやフォーマッターがその典型で、たとえば「未使用の変数がある」というコードを渡せば、何度実行しても必ず同じ警告を返す。気分や文脈によって判断が揺れることがない。

対照的に、LLM は非決定論的だ。同じコードを渡しても、実行するたびにチェックの粒度や指摘内容がブレる。「インデントを揃えて」と指示しても、ある時はスペース 2 つ、別の時はタブで揃えるかもしれない。

だからこそ、機械的に判定できるルール（構文エラー、未使用変数、フォーマット）は LLM に任せず、決定論的ツールに委ねるのが原則だ。PostToolUse Hook でファイル編集のたびにリンターを自動実行し、エラーをエージェントに即時フィードバックする。

言語別の推奨スタック:

言語	PostToolUse	プリコミット	カスタムルール
TypeScript	Biome + Oxlint	tsc + ESLint	eslint-plugin-local-rules
Python	Ruff check/format	Ruff + mypy	ast-grep
Go	gofumpt + golangci-lint	同左	ast-grep

リンター設定の保護も重要だ。エージェントがルールを勝手に緩和・改ざんするのを防ぐ仕組みが必要になる。これはまさに「手綱」の役割 — エージェントが暴走しないよう、作業のたびに自動で引き戻す仕組みだ。

Harness Engineering ベストプラクティス 2026 — AI コーディングエージェントを安定稼働させる設計術

Mon, 09 Mar 2026 00:00:00 +0000

逆瀬川氏のHarness Engineeringベストプラクティス記事を要約。Hooks 4パターン、リンター戦略、E2Eテスト、CLAUDE.md設計、MVH導入ステップを解説。

Impeccable — AI コーディングツールのフロントエンド設計を底上げするスキルライブラリ

Mon, 09 Mar 2026 00:00:00 +0000

AI コーディングツール（Claude Code、Cursor、Gemini CLI など）で UI を生成すると、「動くけど見た目がイマイチ」になりがちだ。Impeccable は、AI に設計のボキャブラリーを教えることで、生成される UI の品質を引き上げるスキルライブラリだ。

Impeccable とは

Impeccable は、Paul Bakaus 氏が開発した AI コーディングツール向けの設計スキル拡張だ。Anthropic の公式 frontend-design スキルをベースに、17個のコマンドと厳選されたアンチパターン集を提供する。

「派手なデザイン」ではなく「洗練された仕上がり」を目指すのが特徴で、中国のインディー開発者コミュニティでも注目を集めている。

対応ツール

Cursor
Claude Code
Gemini CLI
Codex CLI
VS Code Copilot
Google Antigravity
Kiro

インストール方法

npx（推奨）

1

npx skills add pbakaus/impeccable

Claude Code の場合

1
2
3
4
5


# プロジェクト単位
cp -r dist/claude-code/.claude your-project/

# グローバル
cp -r dist/claude-code/.claude/* ~/.claude/

Cursor の場合

1

cp -r dist/cursor/.cursor your-project/

Nightly チャンネルの使用と Agent Skills の有効化が必要。

Karpathy の autoresearch — AIが寝ている間に100回実験を回す仕組み

Mon, 09 Mar 2026 00:00:00 +0000

Andrej Karpathy が公開した autoresearch は、AI エージェントが単一 GPU 上で自律的に ML 実験を繰り返すツールです。わずか約630行の Python コードで「コード修正 → 学習 → 評価 → 改善」のループを自動化し、研究の競争軸を「コード品質」から「改善ループの速度」へと変えようとしています。

autoresearch とは

autoresearch のコンセプトはシンプルです:

AIエージェントに小さいが本物の LLM トレーニング環境を渡し、一晩中自律的に実験させる

エージェントはトレーニングコード（train.py）を自動修正し、5分間のトレーニングを実行、検証損失（val_bpb）が改善したかを確認し、結果に基づいて次の実験に進みます。

プロジェクト構成

autoresearch はたった3つのファイルで構成されています:

ファイル	役割	編集者
`prepare.py`	データ準備・ランタイムユーティリティ	変更不可
`train.py`	モデル・オプティマイザ・学習ループ	AIエージェント
`program.md`	エージェントへの指示書	人間

従来のML研究では Python ファイルを直接編集しますが、autoresearch では Markdown ファイル（program.md）でエージェントに指示を与える という設計になっています。人間が行うのは「プログラムのプログラミング」です。

固定時間予算という設計判断

autoresearch の重要な設計判断は、全てのトレーニングを ちょうど5分間 に固定していることです:

1時間あたり約12回の実験が可能
一晩（8時間）で約100回の実験を自動実行
プラットフォームに依存せず公平な比較が可能

1
2
3
4
5
6


# セットアップ
uv sync
uv run prepare.py # データ準備（初回のみ、約2分）

# 単一実験の実行
uv run train.py # 約5分で完了

エージェントの起動は、Claude などの AI に対して以下のように指示するだけです:

OpenAI Symphony — AI エージェントを自律的にオーケストレーションするオープンソースフレームワーク

Mon, 09 Mar 2026 00:00:00 +0000

OpenAI が Symphony というオープンソースの自動化基盤をリリースしました。Issue トラッカーから課題を読み取り、課題ごとに隔離ワークスペースを作成し、AI エージェントに実装を走らせるオーケストレーションフレームワークです。

Symphony とは

Symphony は、AI コーディングエージェントを手動のプロンプト操作から構造化された自律実行へと移行させるためのフレームワークです。Elixir / Erlang BEAM ランタイム上に構築されており、長時間実行される独立した「実装ラン（implementation run）」を高い並行性と耐障害性で管理します。

従来の「AI にコードを書かせて PR を出す」という手動プロンプト型のワークフローを、カンバンボードのタスクカードを移動するだけで管理できるようにします。

動作の仕組み

Symphony の基本的な流れは以下の通りです:

課題の読み取り — Issue トラッカー（現在は Linear をサポート）からタスクを継続的に監視
隔離ワークスペースの作成 — 各課題に対して独立したワークスペースを生成
エージェントの実行 — ワークスペース内でコーディングエージェントセッションを実行
成果物の提出 — CI ステータス、PR レビューフィードバック、複雑度分析、操作動画などの「作業証明」を提供
承認とマージ — タスクが承認されると、エージェントが安全に PR をマージ

技術的な特徴

WORKFLOW.md によるエージェント制御

エージェントのプロンプトやランタイム設定は、リポジトリ内の WORKFLOW.md に直接保存されます。これにより、AI の動作指示がコードとしてバージョン管理され、変更対象のブランチと同期されます。

Elixir / BEAM ランタイムの採用

Elixir と Erlang/BEAM ランタイムを採用することで、以下のメリットがあります:

高い並行性 — 複数のエージェントセッションを同時に管理
耐障害性 — 個別の実装ランが失敗してもシステム全体に影響しない
長時間実行への対応 — エージェントの長時間稼働を安定的にサポート

Poll-Dispatch-Resolve-Land ワークフロー

Symphony の中核となるワークフローパターンです:

OpenClaw で月400ドルの AI チームを構築 — 18歳がコーディング経験ゼロで実現した方法

Mon, 09 Mar 2026 00:00:00 +0000

18歳、コーディング経験ゼロ、高校を卒業したばかりの起業家が OpenClaw を使って15人の AI エージェントチームを構築し、月額400ドルで24時間稼働させている事例が話題になっています。GitHubやIDEの知識がなくても、AI チームを組織できる時代が来ています。

OpenClaw とは

OpenClaw は、Peter Steinberger が開発したオープンソースの自律型 AI エージェントです。2026年3月時点で GitHub スター数は約247,000、フォーク数は47,700を超え、爆発的な成長を遂げています。

完全にオープンソースでサブスクリプションや API 費用が不要なため、実際にかかるコストはハードウェアと電気代のみ。専用サーバー（OVH で月45ドル、Hetzner で月40ドル程度）を使えば、低コストで本格的な AI チームを運用できます。

AI チームの構成

YouTube 動画「I Built a Full AI Team Inside OpenClaw for $400/Month」（4.2万回再生）では、以下のような AI エージェントチームの構築が紹介されています:

エージェント名	役割
ATLAS	戦略・計画策定
SCRIBE	ドキュメント・コンテンツ作成
PIXEL	デザイン・ビジュアル
NOVA	リサーチ・分析
SENTINEL	監視・品質管理
CLOSER	セールス・クロージング
CLAND	コーディング・開発
CLIP	動画・メディア編集

各エージェントは agents/ フォルダ内にサブフォルダとして定義され、それぞれの AGENTS.md に役割・ツール・振る舞いが記述されます。

セットアップの仕組み

OpenClaw のマルチエージェント構成は以下のような構造です:

workspace/
├── agents/
│ ├── atlas/
│ │ └── AGENTS.md # 戦略担当の定義
│ ├── scribe/
│ │ └── AGENTS.md # ライティング担当の定義
│ ├── cland/
│ │ └── AGENTS.md # 開発担当の定義
│ └── ...
└── program.md # チーム全体への指示

エージェントは MCP スキルを通じて各種ツールと連携し、Reddit や Twitter のシグナル収集、トレンド分析、コンテンツ生成などを自律的に実行します。

OpenClaw とは何か：話題のオープンソース AI エージェントを徹底解説

Mon, 09 Mar 2026 00:00:00 +0000

2025年末に「Clawdbot」として登場し、2026年に入ってから GitHub スター数20万超を記録した OpenClaw が大きな話題になっています。この記事では、OpenClaw の概要、主要機能、セキュリティ上の注意点、そしてセットアップ方法までを解説します。

OpenClaw とは

OpenClaw は、Peter Steinberger 氏が開発したオープンソースの AI エージェントフレームワークです。従来のチャットボットが「テキストを生成する」だけだったのに対し、OpenClaw は 実際にタスクを実行する 点が最大の特徴です。

公式サイトのキャッチフレーズは “The AI That Actually Does Things” 。ファイル操作、シェルコマンドの実行、Web ブラウジング、フォーム入力など、PC 上のさまざまな操作を AI に任せることができます。

主要機能

チャットプラットフォーム統合

WhatsApp、Telegram、Discord、Slack、Signal、iMessage など、普段使っているメッセージアプリから自然言語で指示を出せます。専用アプリや Web サイトを開く必要はありません。

実行可能なタスク

メール管理: 未読メールの自動分析・優先順位付け、定型返信の作成
スケジュール調整: カレンダー確認、飲食店予約の自動実施
開発支援: GitHub コード履歴の確認、プルリクエストレビュー
ブラウザ制御: Web サイト閲覧、フォーム入力、データ抽出の自動化

ローカルファースト設計

個人デバイスやローカルサーバーで動作し、Raspberry Pi のような低価格デバイスでも実行可能です。クラウド利用時も暗号化環境を採用しています。

永続的メモリ

ユーザーの好みやコンテキストを記憶し、使い込むほど賢くなる仕組みが組み込まれています。

セットアップ方法

Node.js 22 以上が必要です。

1

npm install -g openclaw@latest

インストール後、オンボーディングウィザードで API 設定を完了します。LLM バックエンドは Claude、GPT、Ollama 経由のローカルモデルに対応しており、自分の API キーを使う方式（BYOK）です。

Paperclip — AIエージェントで会社を自律運営するオープンソースOS

Mon, 09 Mar 2026 00:00:00 +0000

AIエージェントに役職・組織図・予算・目標を与え、24時間自律的に会社を運営させる——そんなコンセプトのオープンソースプロジェクト「Paperclip」が公開され、注目を集めている。

Paperclip とは

Paperclip は、複数の AI エージェントを「社員」として組織化し、会社として機能させるためのオーケストレーションプラットフォームだ。

“If OpenClaw is an employee, Paperclip is the company.”

個々の AI エージェントを個別に管理するのではなく、組織図・予算・ガバナンス・目標整合・タスク調整といった会社レベルのインフラを提供する。

GitHub: https://github.com/paperclipai/paperclip
公式サイト: https://paperclip.ing/
ライセンス: MIT

主な機能

エージェントの組織化

組織図（Org Chart）: 階層構造、役職、レポートラインを定義
目標整合（Goal Alignment）: 会社のミッションからプロジェクト目標、個別タスクまで文脈が伝播
マルチカンパニー対応: 1つのデプロイで複数の会社を完全分離して管理

対応エージェント

Claude、OpenClaw、Codex、Cursor、Bash スクリプト、HTTP Webhook など、ハートビートシグナルを受信できる任意のランタイムと連携できる。

コスト管理

エージェントごとに月次予算を設定し、使用量80%で警告、100%で自動停止する。暴走的なトークン消費を防ぐ仕組みが組み込まれている。

ガバナンスと監査

人間による承認ゲート（採用・戦略変更時）
設定変更のバージョニングとロールバック
全ての会話・意思決定・ツール呼び出しの追跡ログ
いつでもエージェントの一時停止・再割り当て・終了が可能

セットアップ

1
2
3
4
5
6
7
8


# クイックスタート
npx paperclipai onboard --yes

# 手動インストール
git clone https://github.com/paperclipai/paperclip.git
cd paperclip
pnpm install
pnpm dev

API は http://localhost:3100 で起動し、組み込みの PostgreSQL データベースを使用する。要件は Node.js 20+ と pnpm 9.15+。

Qwen3.5-27B：個人PCで動く高性能LLMの実力と使い方

Mon, 09 Mar 2026 00:00:00 +0000

Alibaba Cloud の Qwen チームが 2026 年 2 月にリリースした Qwen3.5-27B は、27B パラメータという中規模サイズながら上位モデルに匹敵する性能を発揮する密（dense）モデルです。メモリ効率に優れ、量子化を活用すれば個人の PC でも快適に動作するため「自分専用 AI」を構築するのに最適な選択肢として注目されています。

Qwen3.5-27B の主な特徴

アーキテクチャ

Qwen3.5-27B は MoE（Mixture of Experts）ではなく、全パラメータが推論時に活性化される 密モデル（dense model） です。Gated Delta Networks と Feed Forward Networks を組み合わせた構造で、高い計算密度を実現しています。

パラメータ数: 27B（全パラメータ活性化）
コンテキスト長: 262K トークン（最大 1M まで拡張可能）
対応言語: 201 言語
マルチモーダル: 視覚・言語の統合能力を搭載

ベンチマーク性能

27B というサイズにもかかわらず、主要ベンチマークで際立った成績を残しています。

ベンチマーク	スコア
MMLU-Pro	86.1%
GPQA Diamond	85.5%
SWE-bench Verified	72.4%
LiveCodeBench	80.7%
IFEval	95.0%
HMMT（数学）	92.0%

特に SWE-bench Verified で 72.4% は GPT-5 mini と同等の数値であり、オープンウェイトの 27B 密モデルとしては驚異的な結果です。コーディング、数学、指示追従の各タスクで中規模モデルカテゴリをリードしています。

深圳が世界初の OpenClaw・一人企業支援策を発表 — AI エージェント時代のソロ起業を後押し

Mon, 09 Mar 2026 00:00:00 +0000

深圳市龍崗区が「OpenClaw および OPC（One-Person Company）発展支援に関する若干の措置」を発表した。AI エージェントフレームワーク OpenClaw と「一人企業」モデルを対象にした政府支援策としては、中国初、おそらく世界初の試みだ。荒井健一氏（@aarai666）のツイートで紹介されたこの政策の要点を整理する。

OpenClaw とは何か

OpenClaw はオーストリアの Peter Steinberger 氏が開発したオープンソースの AI アシスタントだ。フライトの予約からメール整理まで幅広いタスクを自律的にこなし、個人が数人分のチームに匹敵する生産性を発揮できる。この仕組みを活用して一人で会社を運営する「OPC（One-Person Company）」というコンセプトが、中国を中心に急速に広がっている。

中国では無料インストールイベントに数千人が参加するなど爆発的な人気を見せており、李強首相が全国人民代表大会で「スマートエージェント」（OpenClaw を含む概念）に言及するほどの注目度だ。

深圳・龍崗区の支援策

龍崗区の政策は、概念の認知からわずか約 3 週間で正式な支援策にまとめ上げるスピード感を見せた。支援は大きく 3 つの柱で構成される。

1. 導入・開発支援

「ロブスターサービスゾーン」を設置し無料で OpenClaw の導入サービスを提供するプラットフォームに、最大 200 万元（約 4,000 万円）の補助金
コード貢献やスキルパッケージ開発を行う開発者への追加資金支援
関連技術パッケージの開発・配布企業に最大 200 万元 の助成金

2. 計算・データリソース

データサービス、AI NAS ハードウェア、大規模モデル API 利用料の 30〜50% を補助
OPC コミュニティに新規入居する企業に 3 ヶ月間 の無料計算リソースを提供

3. 総合的な起業支援

2 ヶ月間 の無料住居提供
18 ヶ月間 の割引オフィススペース
人材定着助成金として最大 10 万元（約 200 万円）
エクイティ投資として最大 1,000 万元（約 2 億円）

政策の戦略的目標は「初期の起業コストをゼロ水準まで引き下げ、深圳を AI エージェントスタートアップのハブにする」ことだ。

Claude Codeのハルシネーション対策 — Anti-Hallucination Protocolという考え方

Sun, 08 Mar 2026 00:00:00 +0000

Claude Code などの LLM エージェントを業務で使う際、最大のリスクは**ハルシネーション（幻覚）**です。プロンプトの改善ばかりが注目されがちですが、本当に必要なのは「仕組みで縛る」アプローチです。

きっかけとなった事故

ある開発者が実際に遭遇した事故が、この議論のきっかけです:

which コマンドの結果だけで「未インストール」と診断されたが、コードは PATH 外のディレクトリを直接参照していた。ログを1行も読まずに断言。

LLM エージェントは自信に満ちた口調で誤った結論を出すことがあり、人間がそれを鵜呑みにしてしまうリスクがあります。

Anti-Hallucination Protocol の4つの柱

提唱されている Anti-Hallucination Protocol は、以下の4つのルールで構成されます:

1. 事実主張にはツール実行による検証を義務化

LLM が「〜がインストールされていない」「〜が原因です」と主張する場合、必ず対応するコマンドやツールを実行して裏付けを取ることを求めます。推測だけで結論を出すことを許容しません。

2. 禁止パターンの明示

以下の4つのパターンを明示的に禁止します:

パターン	説明
推測診断	十分な証拠なしに原因を断定する
確認なし否定	実際に確認せず「存在しない」「動かない」と主張する
記憶による主張	過去の学習データだけに基づく事実主張
自信に満ちた誤り	高い確信度で不正確な情報を提供する

3. 違反時のインシデント記録と伝播

ハルシネーションが検出された場合、インシデントとして記録し、全プロジェクト横断で伝播させます。これにより同じ失敗パターンを繰り返さない仕組みを構築します。

4. プロジェクト設定への組み込み

CLAUDE.md や類似の設定ファイルにルールを記述し、プロジェクト単位で一貫したガードレールを維持します。

2026年のハルシネーション対策の現状

2026年3月時点で、各 LLM のハルシネーション率は改善が進んでいます。LLM Hallucination Index 2026 によると、Claude Sonnet 4.6 は BS 検出成功率 91.0%、誤検出率 3.0% とトップクラスの精度を示しています。

しかし、モデル性能の向上だけでは不十分です。特に以下の場面ではハルシネーションが発生しやすいことが報告されています:

コンテキスト圧縮後: 長い会話でコンテキストが圧縮されると、計画と実装の乖離が起きやすい
Plan Mode での実装フェーズ: 計画作成後の実装で、計画にない機能を追加してしまう

実践的な対策

CLAUDE.md への記述例

1
2
3
4
5
6


## Anti-Hallucination Rules

- ファイルの存在確認は必ず `ls` や `cat` で実行すること
- パッケージのインストール状況は `which` だけでなく、実際のインポートやバージョン確認で検証すること
- エラーの原因を主張する前に、必ずログファイルを読むこと
- 「〜のはずです」「おそらく〜」という推測を事実として扱わないこと

CLEO のようなツールの活用

CLEO は Claude Code 向けのタスク管理ツールで、4層の Anti-Hallucination 保護と SQLite による不変の監査証跡を提供します。

OpenClaw × Telegram Forum Topics — AIとの対話を構造化して生産性を上げる方法

Sun, 08 Mar 2026 00:00:00 +0000

OpenClaw を Telegram で使っている人に向けて、Forum Topics を活用した構造化テクニックが海外で話題になっています。ブックマーク 2,000 件を突破したこの手法を紹介します。

Forum Topics でできること

Telegram の Forum Topics 機能を OpenClaw と組み合わせると、以下のことが実現できます:

会話をカテゴリ分け — 仕事、開発、健康、趣味など、トピックごとに独立した LLM セッションを持てる
文脈が混ざらない — 各トピックが独立したセッションになるため、異なるコンテキストが干渉しない
cron ジョブ・定期通知の自動ルーティング — 関連するトピックに自動で振り分け
メール転送による自動処理 — ボットにメールを転送するだけで、適切なトピックで自動的に処理

設定方法

設定はシンプルです:

BotFather で「Threaded Mode」を ON にする
OpenClaw に Forum Topics を使うよう指示する

これだけで、トピックベースの構造化された AI アシスタント環境が整います。

実践例: AI が部門別の秘書チームになる

この手法を紹介した Typefully の共同創業者は、実際に自分のプロダクト運用でこの構造を活用しています:

トピック	用途
General	一般的なやり取り
Dev	開発タスク管理
Life	日常のタスク
Health	健康管理
Racing	レース準備
Finances	財務管理

まさに AI が部門別の秘書チーム として機能している状態です。

OpenRouter で AI モデルを一元管理する — コスト削減と効率化の実践

Sun, 08 Mar 2026 00:00:00 +0000

AI モデルの利用が増えるにつれ、複数のプロバイダの API キーを管理する煩雑さやコストの把握が難しくなっていく。OpenRouter を使えば、1つの API キーで複数の AI モデルにアクセスでき、コスト管理も一元化できる。

OpenRouter とは

OpenRouter は、複数の AI モデルプロバイダ（OpenAI、Anthropic、Google、Meta など）のモデルに単一の API エンドポイントからアクセスできるルーティングサービスだ。OpenAI 互換の API 形式を採用しているため、既存のコードからの移行も容易になっている。

料金体系

OpenRouter は無料から始められる。クレジットカードの登録も不要だ。

無料モデル: DeepSeek V3/R1、Google、Meta、Mistral など約27種類のモデルが無料で利用可能（1日50リクエスト、1分20リクエストの制限あり）
有料モデル: Claude や GPT-4 などのプレミアムモデルはプロバイダの正規料金で従量課金。最低金額やロックインなし
BYOK（自分の API キー持ち込み）: 月100万リクエストまで無料。以降は通常料金の5%の手数料

OpenRouter を使う3つのメリット

1. コスト効率の向上

各プロバイダと個別に契約する代わりに、OpenRouter 経由で利用することで支出を一元管理できる。用途に応じて安価なモデルと高性能なモデルを使い分けることで、全体のコストを最適化できる。

2. API キーの一元管理

複数のプロバイダの API キーを管理する必要がなくなる。1つの OpenRouter API キーだけで、さまざまなモデルにアクセスできる。

1
2


# OpenRouter API キーを設定するだけで複数モデルにアクセス可能
export OPENROUTER_API_KEY="sk-or-..."

3. 最新モデルへの素早い切り替え

新しいモデルがリリースされた際、OpenRouter 上で利用可能になればすぐに試すことができる。プロバイダごとにアカウント登録や API キー発行をする必要がない。

# OpenHands × Ollama ローカルLLM実践記 — Mac Studio M3 Ultra で動かすまでの全記録

Fri, 06 Mar 2026 00:00:00 +0000

OpenHands × Ollama ローカルLLM実践記 — Mac Studio M3 Ultra で動かすまでの全記録

TL;DR: OpenHands（旧OpenDevin）をMac Studio M3 Ultra（96GB）+ Ollama + Qwen3-Coder 30B で動かそうとした。Docker-in-Docker のビルド問題、Playwright依存、ランタイムイメージ手動構築を経てUI起動まで到達したが、30Bモデルのtool calling精度不足で実用には至らなかった。

1. OpenHands とは

OpenHands（旧 OpenDevin）は、オープンソースのAIコーディングエージェントプラットフォーム。75以上のLLMプロバイダーに対応し、SWE-bench で Qwen3-Coder 使用時に 69.6% のスコアを記録している。

公式リポジトリ: https://github.com/All-Hands-AI/OpenHands

特徴:

Web UI でブラウザから操作
Docker サンドボックスで安全にコード実行
CodeActAgent による自律的なタスク遂行
Playwright 統合によるブラウザ操作

2. 動機 — なぜ OpenHands を試したか

前回の実験で Qwen Code（CLI エージェント）を Ollama + Qwen3-Coder 30B で動かしたが、複雑な multi-step タスク（GitHub PR レビューなど）で tool calling が破綻する問題に直面した。

OpenHands は SWE-bench で高スコアを出しており、エージェントスキャフォールディングの力で同じ 30B モデルでも改善されるのでは？という仮説を検証するために試した。

ChatGPT音声モード × 14日間英会話特訓 — 詰まった言葉がスラスラ出る4つの黄金プロンプト

Fri, 06 Mar 2026 00:00:00 +0000

ChatGPT 音声モード × 14 日間英会話特訓 — 詰まった言葉がスラスラ出る 4 つの黄金プロンプト

@technocrat_s 氏のポストで紹介された記事が話題になっています。

【検証】ChatGPTと14日間、ガチの「英会話」特訓。詰まった言葉がスラスラ出る黄金プロンプト4つ

ライフハッカー・ジャパンの記事（原文: MakeUseOf / Saikat Basu）は、在宅勤務でスピーキング力が錆びついたライターが ChatGPT の高度音声モード（Advanced Voice Mode）をコーチに見立て、14 日間の集中特訓を行った検証記事です。思考と発話の間の「0.5 秒の遅れ」を消すために設計された 4 つのプロンプトと、その結果を具体的に報告しています。

問題 — 「考えてから話す」0.5 秒の壁

著者の Saikat Basu 氏は MakeUseOf の元編集者で、MBA を持つテクノロジーライターです。在宅勤務が長くなるにつれ、ビデオ会議やチームコールで英語の発話に遅れが生じるようになりました。

在宅ワーカーのスピーキング劣化:
思考 → [0.5 秒の遅れ] → 発話
↑
・フィラー語（um, uh）の増加
・語彙が出てこない
・文法ミスの自己修正ができない
・発音の曖昧化

「知っている英語」と「口から出る英語」の間にギャップがある — これは日本人英語学習者にも共通する課題です。文法や語彙の知識があっても、リアルタイムの発話ではその知識を引き出せない。Basu 氏はこのギャップを ChatGPT の音声モードで埋められるかを検証しました。

ChatGPT 高度音声モード — AI が「聞いて、話して、直す」

ChatGPT の Advanced Voice Mode は 2024 年後半に GPT-4o ベースで登場し、2025 年以降は無料ユーザーにも開放されています。

特徴	従来のテキストチャット	高度音声モード
応答速度	テキスト入力→テキスト出力	リアルタイム音声対話
発音フィードバック	不可能	母音・子音レベルで指摘可能
会話の自然さ	ターン制	割り込み・相槌あり
感情表現	なし	9 種類のアクセント・声質選択
練習の心理的障壁	低い	低い（相手が AI なので恥ずかしくない）

従来の英会話レッスンとの最大の違いは予約不要・24 時間・何度でもやり直せることです。また「相手が AI なので失敗が恥ずかしくない」という心理的安全性も、スピーキング練習では非常に重要です。

Qwen Code ローカル運用実践記 — Mac Studio M3 Ultra で Ollama + qwen3-coder:30b を動かして分かったこと

Fri, 06 Mar 2026 00:00:00 +0000

Qwen Code ローカル運用実践記 — Mac Studio M3 Ultra で Ollama + qwen3-coder:30b を動かして分かったこと

Qwen Code（Alibaba Cloud Qwen チームが開発したオープンソース CLI コーディングエージェント）を Mac Studio M3 Ultra（96GB）上で Ollama と組み合わせてローカル運用を試みた実践記録です。環境構築からツール呼び出しの限界まで、実際に手を動かして検証した結果をまとめます。

背景と目的

Claude Code は強力ですが、コードがクラウドに送信されるためプライバシーの懸念があります。Qwen Code は Apache 2.0 ライセンスのオープンソースで、Ollama と組み合わせれば完全ローカルで動作するため、機密コードベースでの利用が期待されます。

本記事の検証環境:

項目	スペック
マシン	Mac Studio M3 Ultra
メモリ	96GB ユニファイドメモリ
メモリ帯域	800 GB/s
Ollama	v0.15.6
Qwen Code	v0.12.0（Fork からローカルビルド）
モデル	qwen3-coder:30b (18GB)

ステップ1: リポジトリの Fork と Clone

調査・改造を前提に、まず QwenLM/qwen-code を Fork しました。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# Fork（GitHub CLI）
gh repo fork QwenLM/qwen-code --clone=false

# devel ブランチを作成してデフォルトに設定
# main は upstream との sync 用にクリーンに保つ
gh api repos/hdknr/qwen-code/git/refs \
 -f ref="refs/heads/devel" \
 -f sha="$(gh api repos/hdknr/qwen-code/git/ref/heads/main --jq '.object.sha')"
gh repo edit hdknr/qwen-code --default-branch devel

# Clone
mkdir -p ~/Projects/qwen
cd ~/Projects/qwen
gh repo clone hdknr/qwen-code

ブランチ戦略:

Qwen Code 初心者ガイド — 無料で使えるオープンソース CLI コーディングエージェント

Fri, 06 Mar 2026 00:00:00 +0000

Qwen Code 初心者ガイド — 無料で使えるオープンソース CLI コーディングエージェント

Claude Code の無料オープンソース代替として注目を集めている Qwen Code。Alibaba Cloud の Qwen チームが開発したターミナルベースの AI コーディングエージェントで、1日1,000リクエストまで無料で利用できます。この記事では、初めて使う人にもわかるように、インストールから実践的な使い方まで解説します。

Qwen Code とは何か

Qwen Code は、ターミナル（コマンドライン）で動く AI コーディングアシスタントです。自然言語で指示を出すと、コードの理解・生成・編集・実行を自律的に行います。

一言で言うと

「無料で使える Claude Code のオープンソース版」

Claude Code との違い

観点	Qwen Code	Claude Code
料金	無料（OAuth で1日1,000リクエスト）	従量課金（API 使用量に応じて）
ライセンス	Apache 2.0（オープンソース）	プロプライエタリ
ベースモデル	Qwen3-Coder	Claude
インターフェース	ターミナル CLI	ターミナル CLI
IDE 統合	VS Code, Zed, JetBrains	VS Code, JetBrains
MCP サポート	あり	あり
コード品質	実用的（オープンモデルとしてトップクラス）	最高品質
カスタマイズ	完全にカスタマイズ可能	限定的

できること

コードベース全体を理解して質問に答える
ファイルの作成・編集・削除
シェルコマンドの実行
Git 操作（コミット、diff 確認等）
バグの発見と修正
テストの作成と実行
MCP サーバーとの連携

インストール手順

前提条件

Node.js 20 以上が必要です。まだインストールしていない場合は nodejs.org からダウンロードしてください。

「AIに評価されている」と知った人は量を増やし質を落とす — アルゴリズム評価の隠れたコスト

Thu, 05 Mar 2026 00:00:00 +0000

「AIに評価されている」と知った人は量を増やし質を落とす — アルゴリズム評価の隠れたコスト

@ai_database（AIDB）のポストが話題になっています。

提出物をAIでレビューするツールや、実際にそれらを使用する人も増えている中、今回カリフォルニア大学などの研究者らは「“AIで仕事を評価されている"と知った人は"アウトプットの量は増えるが中身が薄くなる”」という現象が有意にあることを実験で確認しました。

カリフォルニア大学サンタバーバラ校（UCSB）の David Almog、Lucas Lippman、Daniel Martin らが 2026 年 3 月に発表した論文「When an AI Judges Your Work: The Hidden Costs of Algorithmic Assessment」は、AI 評価が人間の行動を構造的に変えてしまうことを実験で証明しました。量は増えるが質は落ちる、外部ツールへの依存は倍増する、高得点の喜びは薄れる — 「AIがだましやすいから手を抜く」ではなく、人間の目の有無がモチベーションそのものを変えるという発見です。

実験の設計 — 208 人の画像説明タスク

研究チームは 208 人の参加者をランダムに 2 グループに分けました。

グループ	人数	評価者
人間評価グループ	103 人	人間の評価者が採点すると事前に告知
ChatGPT 評価グループ	105 人	ChatGPT が採点すると事前に告知

タスクは 20 枚の日常風景画像に対して 150〜400 文字の説明文を書くことです。評価基準は「興味深さ」「努力」「正確さ」の 3 項目で、各 0〜3 点（合計 9 点満点）です。

重要なのは、両グループとも実際の評価方法は同じだったことです。違うのは「誰に評価されると思っているか」だけです。つまり、この実験が測定しているのは AI の評価能力ではなく、「AI に評価される」という認知が人間の行動をどう変えるかです。

結果 — 量は増え、質は落ちる

量の増加

出力文字数:
人間評価グループ: 229 文字（平均）
ChatGPT評価グループ: 251 文字（平均） → +9.6%（p < 0.0001）
作成時間:
人間評価グループ: 94 秒（平均）
ChatGPT評価グループ: 85 秒（平均） → -9.6%（p < 0.0001）

ChatGPT 評価グループはより短い時間で、より多くの文字数を生産しました。一見すると生産性が向上しているように見えます。

「Claude Code無料で無制限」は本当か × ollama launch claudeの実態と品質ギャップの正直な話

Thu, 05 Mar 2026 00:00:00 +0000

「Claude Code が無料で無制限」は本当か — ollama launch claude の実態と品質ギャップの正直な話

@TusharSoni014 氏の X 投稿が 10 万回以上表示され、2,227 件のブックマークを集めています。

Want Claude Code Unlimited FREE? Follow,

Download Ollama

Install Qwen3.5 9B

Run this command in your terminal, ollama launch claude –model qwen3.5:9b

Enjoy Unlimited Claude Code fully running 100% Free

「Claude Code が完全に無料で無制限に使える」という主張です。1,311 件のいいねと 127 件のリツイートを見ると、多くの人がこの情報に飛びついたことがわかります。

結論から言えば、コマンド自体は実在しますが、「Claude Code が無料で動く」という表現は大きな誤解を招きます。正確に何が起きているのか、何が失われるのかを解説します。

ollama launch claude は実在する

コマンドの正体

ollama launch は、Ollama v0.15 で追加された公式コマンドです。Claude Code、OpenCode、Codex などのコーディングツールを、環境変数や設定ファイルなしで起動できるようにするものです。

1
2
3
4


# 基本的な使い方
ollama launch claude # インタラクティブにモデルを選択
ollama launch claude --model qwen3-coder # モデルを指定して起動
ollama launch claude --model qwen3.5:9b # ツイートの例

このコマンドが裏でやっていることは、Ollama の Anthropic Messages API 互換モードを利用して、ローカルの LLM を Claude Code のバックエンドとして接続することです。

「あなたは何者？」— 職能の境界が溶けた AI 時代に、認知パターンで自分を再定義する

Thu, 05 Mar 2026 00:00:00 +0000

「あなたは何者？」— 職能の境界が溶けた AI 時代に、認知パターンで自分を再定義する

@yamashitakazuki 氏（山下一樹氏）のポストが、生成 AI によって「デザイナー」「エンジニア」という職能の境界が溶けつつある今、自分を認知パターンから捉え直す視点を提案しています。@kgsi 氏が「迷ってるデザイナーにこそ見てほしい記事」として紹介し、反響を呼んでいます。

迷ってるデザイナーにこそ見てほしい記事。生成AIで職能の境界が溶けていく中で、「自分は何者か」を肩書きではなく"認知パターン"から捉え直そうという話。実行者・調整者・構想者・深化者——自分も読みながら近しいタイプがあって、なんだか輪郭がはっきりした感覚があった。

山下氏は、Donna Dunning の著書 “What’s Your Type of Career?” (2001) をベースに、職能（何ができるか）ではなく認知パターン（どう考え、どう動くか）でキャリアを見つめ直すフレームワークを提示しています。

問いの構造 — なぜ「何者」が問われるのか

職能の境界が溶けている

2026年現在、生成 AI は職能の境界を急速に溶かしています。

従来	現在
UI デザインはデザイナーの仕事	エンジニアが AI でモックアップを作れる
コーディングはエンジニアの仕事	デザイナーが Claude Code でアプリを作れる
設計書はアーキテクトの仕事	PM が AI で技術仕様を書ける
テストは QA の仕事	誰でも AI でテストコードを生成できる

AI がコードの8割を自動生成し、デザインツールが自然言語で操作でき、文章も翻訳も AI が担う。「何ができるか」で自分を定義していた人ほど、足元が揺らいでいます。

職能は「ペルソナ」に過ぎない

山下氏の指摘は鋭いものです。

職能はその人をとりあえず認識するのにとても便利ですが、あくまでペルソナであり、仕事上の姿であり、自分がどういう人かをまったく示しません。

「デザイナー」「エンジニア」という肩書きは、その人が何をするかは示しますが、どう考え、どう動くかは見えません。同じ「デザイナー」でも、全体を俯瞰して構造から入る人と、ディテールを積み上げて形にしていく人では、プロジェクトへの関わり方が根本的に違います。

4つの認知パターン — 実行者・調整者・構想者・深化者

山下氏は、Donna Dunning の「8 Ways of Working」を土台に、認知パターンを4つの大分類に集約しています。

一覧

認知パターン	特徴	プロジェクトでの役割
実行者	状況を即座に読み取り、実行し動かすことで価値を生む	手を動かし、具体的な成果を出す
調整者	人とプロセスをつなぎ、基盤と関係を安定させる	チームの連携を保ち、プロセスを回す
構想者	まだ見えていない可能性に視点と構想を持ち、方向を示す	ビジョンを描き、方向性を定める
深化者	ひとつのことを掘り下げ、質と精度を高め続ける	専門性を深め、品質を担保する

職能 vs 認知パターン

職能で見た場合:
デザイナー A（UI デザイン）
デザイナー B（UI デザイン）
→ 同じ「デザイナー」に見える
認知パターンで見た場合:
デザイナー A（構想者）→ 全体を俯瞰し、ユーザー体験の方向性を示す
デザイナー B（深化者）→ ディテールを追求し、インタラクションの質を高める
→ まったく異なる人物が見える

プロジェクトの進み方を左右しているのは、職能の違いよりも認知パターンの違いだと山下氏は指摘します。

Agentic AI の仕組み — 4層アーキテクチャで理解する「考えて動く AI」の全体像

Thu, 05 Mar 2026 00:00:00 +0000

Agentic AI の仕組み — 4層アーキテクチャで理解する「考えて動く AI」の全体像

Ronald van Loon さん（@Ronald_vanLoon）が、@Python_Dv 作成の Agentic AI アーキテクチャ図を共有し、注目を集めています。

How #AgenticAI works

https://x.com/Ronald_vanLoon/status/2029305639546060814

このインフォグラフィックは、Agentic AI の動作原理を Input Sources → AI Processing → Action Layer → Output の4層で整理しています。「生成 AI と何が違うのか」「なぜ自律的に動けるのか」を、この4層構造を軸に解説します。

生成 AI と Agentic AI の根本的な違い

まず前提を整理します。生成 AI（Generative AI）と Agentic AI は、AI の進化の段階が異なります。

観点	生成 AI	Agentic AI
基本動作	プロンプトに対してコンテンツを生成	目標に向かって自律的に行動
姿勢	受動的（聞かれたら答える）	能動的（自分で判断して動く）
タスク範囲	1回のやり取りで完結	複数ステップを跨いで継続
外部連携	なし（テキスト入出力のみ）	API・ツール・データベースと連携
記憶	セッション内のみ	セッション間で永続化可能
自己修正	なし	エラーを検知して自動リカバリー

IBM は両者の関係を端的にまとめています。「生成 AI は考えて話す。Agentic AI は計画して実行する」。

Agentic AI 学習ロードマップ — 「フルスタックインテリジェンス」を9ヶ月で習得する体系的な道筋

Thu, 05 Mar 2026 00:00:00 +0000

Agentic AI 学習ロードマップ — 「フルスタックインテリジェンス」を9ヶ月で習得する体系的な道筋

@ingliguori 氏（Giuliano Liguori）のポストが、Agentic AI を学ぶためのロードマップを共有しています。

Roadmap to learn Agentic AI: AI fundamentals → Python + frameworks → LLMs → Agents architecture → Memory + RAG → Planning & decision-making → RL & self-improvement → Deployment → Real-world automation Agentic AI = full-stack intelligence.

「Agentic AI = フルスタックインテリジェンス」というフレーズが示すように、AI エージェントの開発には基礎数学からデプロイまで、フルスタックの知識が求められます。本記事では、このロードマップを複数の学習リソースと照合しながら、各段階で何を学び、どのツールを使い、どこまでを目指すのかを体系的に解説します。

ロードマップの全体像

Liguori 氏が示した9ステップを、Scaler の9ヶ月ロードマップと roadmap.sh の AI Agents ロードマップを参考に、時系列で整理します。

月0-1 AI Fundamentals ← 数学 + ML 基礎
月1-2 Python + Frameworks ← API + ライブラリ
月2-3 LLMs ← Transformer + プロンプト
月3-4 Agents Architecture ← ReAct + ツール使用
月4-5 Memory + RAG ← ベクトル DB + 検索拡張
月5-6 Planning & Decision ← 計画 + マルチエージェント
月6-7 RL & Self-improvement ← フィードバック + 自律性
月7-8 Deployment ← MLOps + 監視
月8-9 Real-world Automation ← ポートフォリオ + 実案件

Step 1: AI Fundamentals（月0-1）

学ぶこと

分野	具体的な内容
線形代数	ベクトル、行列演算、固有値分解、SVD
微積分	勾配、偏微分、最適化
確率・統計	ベイズの定理、分布、仮説検定
ML 基礎	教師あり/なし学習、評価指標

推奨リソース

Khan Academy — 数学基礎
“Mathematics for Machine Learning”（書籍）
StatQuest — 統計の直感的理解

この段階のゴール

「なぜニューラルネットワークが動くのか」を数学的に説明できること。数式を書ける必要はないが、勾配降下法やベイズ推論の直感を持つことが重要です。

Agentic AIの周期表 — 66要素で読み解くAIエージェント構築の全体像

Thu, 05 Mar 2026 00:00:00 +0000

Agentic AI の周期表 — 66 要素で読み解く AI エージェント構築の全体像

@ingliguori（Giuliano Liguori）氏のポストが話題になっています。

Agentic AI now has its own “Periodic Table”. From: LLM, RAG, RL to PLAN, MAS, LTM to SAFE, HUMAN oversight to HR, MKT, LEGAL use cases. Autonomous AI = memory + planning + tools + safety + collaboration. It’s a system, not a prompt.

Capital One の Chief Scientist である Prem Natarajan 氏が、AI エージェント構築に必要な 66 の要素を化学の周期表のように体系化した「Agentic AI Periodic Table」を公開しました。LLM や RAG といった基盤技術から、メモリシステム、安全性プロトコル、業務適用まで、エージェント開発の全領域を一枚の表に凝縮しています。

AI/ML学習リポジトリ厳選10選 × スター総計12万超のキュレーション集を目的別に読み解く

Thu, 05 Mar 2026 00:00:00 +0000

AI/ML 学習リポジトリ厳選 10 選 — スター総計 12 万超のキュレーション集を目的別に読み解く

@DeRonin_ 氏が X で投稿した、AI/ML 学習用 GitHub リポジトリのキュレーションが反響を呼んでいます。

List of THE BEST Github Repositories to learn AI and ML

この投稿は 278 件のブックマークを集め、実務者が「手元に置きたいリスト」として支持されていることがわかります。本記事では、紹介された 10 リポジトリを目的別に分類し、それぞれの特徴と使い分けを解説します。

全 10 リポジトリ一覧

#	リポジトリ	スター	主な内容
1	SkalskiP/courses	6.4k	AI コースのキュレーション集
2	owainlewis/awesome-artificial-intelligence	10k+	AI システム構築のリソース集
3	Yorko/mlcourse.ai	—	OpenDataScience の ML コース
4	tirthajyoti/Papers-Literature-ML-DL-RL-AI	—	論文・文献・書籍のカタログ
5	dair-ai/ML-YouTube-Courses	17.1k	YouTube ML コースのインデックス
6	dair-ai/Prompt-Engineering-Guide	71.1k	プロンプトエンジニアリングガイド
7	armankhondker/awesome-ai-ml-resources	—	ML/AI 学習ロードマップ
8	nivu/ai_all_resources	—	数学から DL まで網羅的リソース集
9	aishwaryanr/awesome-generative-ai-guide	25.1k	生成 AI 特化のハブ
10	break-into-data/ai-engineer-toolkit	2.1k	AI エンジニア向けツールキット

目的別分類

10 リポジトリは大きく 4 つのカテゴリに分けられます。

AIVideo Agent — 「動画版 OpenClaw」が24時間コンテンツパイプラインを自律運用する仕組み

Thu, 05 Mar 2026 00:00:00 +0000

AIVideo Agent — 「動画版 OpenClaw」が24時間コンテンツパイプラインを自律運用する仕組み

Hasan Toor 氏（@hasantoxr、フォロワー42万人）が「動画制作の OpenClaw が登場した」と紹介して話題になっています。

BREAKING: The「OpenClaw for video production」just dropped. It’s called AIVideo Agent and it runs your entire content pipeline 24/7 entirely on its own. No API keys. No technical setup. No configuration screens. Just tell it what you want. It ships.

ブックマーク 1,949、閲覧数 93,000 超と大きな反響を呼んでいるこの投稿が紹介しているのは、Y Combinator 出身の AIVideo.com が提供する Video Composer Agent です。「API キー不要、技術セットアップ不要、設定画面なし」という訴求は、OpenClaw が「チャットで指示するだけ」でタスクを実行するのと同じ発想を動画制作に持ち込んだものです。

OpenClaw が変えた「エージェント＝非エンジニア向け」の期待値

AIVideo Agent が「OpenClaw for video production」と呼ばれる背景を理解するには、OpenClaw が何を変えたのかを押さえる必要があります。

awesome-claws × OpenClawエコシステム28エージェント完全マップと設計思想5分類

Thu, 05 Mar 2026 00:00:00 +0000

awesome-claws — OpenClaw エコシステム 28 エージェント完全マップ

@tom_doerr 氏が X で紹介した、OpenClaw インスパイアのエージェントキュレーションリストが注目されています。

List of agents for OpenClaw

machinae/awesome-claws は、OpenClaw にインスパイアされた 28 の AI エージェントプロジェクトをキュレーションしたリストです。Rust、TypeScript、Python、Go、C、Zig まで、8 言語にまたがるエコシステムが形成されています。

本記事では、GitHub 史上最速で最多スターを獲得した OpenClaw の背景と、そこから派生した 28 エージェントを設計思想別に分類して解説します。

OpenClaw とは何か

GitHub 史上最速の成長

OpenClaw は、オーストリアの開発者 Peter Steinberger 氏が開発したオープンソースの自律型 AI エージェントです。

指標	数値
GitHub スター	247,000+（2026 年 3 月時点）
14 日間での獲得スター	190,000（GitHub 史上最速）
フォーク数	47,700+
対応チャネル	20+（WhatsApp、Telegram、Slack 等）
AgentSkills	5,700+

比較として、Kubernetes は約 10 年で 120,000 スター、Linux カーネルは 30 年以上で 195,000 スターです。OpenClaw は 14 日で 190,000 スターを達成し、React を抜いて GitHub 最多スターのソフトウェアプロジェクトになりました。

Claude Code が .env を読んでログに出した — MCC 乗っ取り8桁被害の原因が特定された

Thu, 05 Mar 2026 00:00:00 +0000

Claude Code が .env を読んでログに出した — MCC 乗っ取り8桁被害の原因が特定された

広告の裏側（@hassii_ad）が、先日話題になった Google Ads MCC 乗っ取り事件の続報を投稿しました。いいね 2,558、ブックマーク 2,154、閲覧数 94 万超と大きな反響を呼んでいます。

【続報】原因が特定されました。・Antigravity は無関係、Claude Code で起きてた。・重要操作は人間の承認が必要な設定になっていたが、問題は権限ではなかった。 Claude Code が .env を読み込んだ（読み込み禁止にしてたのに無視されてた）→ その中の認証情報がログに出力されてた。→ 漏洩して悪用された。

初報（閲覧数 286 万、ブックマーク 5,399）では「被害額 8 桁後半」「原因不明」と報告されていましたが、続報で攻撃経路が確定しました。Antigravity は無関係で、Claude Code 単体の問題だったことが明らかになっています。

何が起きたのか — 攻撃の全体像

Claude Code が .env ファイルを読み込む
（.claudeignore で禁止していたが無視された）
↓
.env 内の Google Ads 認証情報がログ（stdout）に出力される
↓
ログ経由で認証情報が漏洩
↓
攻撃者が MCC（マイクライアントセンター）にログイン
↓
配下の全広告アカウントを使って深夜に不正広告を配信
↓
アラートは飛んだが、当事者が目覚めた頃には被害拡大済み

ポイントは「権限設定の問題ではなかった」という点です。重要操作には人間の承認が必要な設定にしていました。しかし Claude Code が .env を読み取って認証情報を stdout に出力するという想定外の挙動により、権限管理を迂回して情報が漏洩しました。

Claude Code に潜んでいた3つの脆弱性 — git clone だけで API キーが盗まれる仕組み

Thu, 05 Mar 2026 00:00:00 +0000

Claude Code に潜んでいた3つの脆弱性 — git clone だけで API キーが盗まれる仕組み

AIコーディングツール Claude Code に、リポジトリをクローンするだけでリモートコード実行（RCE）や API キー窃取が可能になる深刻な脆弱性が見つかった。発見したのはイスラエルのセキュリティ企業 Check Point Research。2025年7月〜2026年1月にかけて段階的に報告・修正された3件の脆弱性は、AI開発ツール特有の「設定ファイル＝実行レイヤー」という新しい攻撃面を浮き彫りにしている。

何が起きたのか — 3行まとめ

Hooks コードインジェクション — .claude/settings.json に仕込んだフックで任意コマンドが実行される
MCP 同意バイパス — enableAllProjectMcpServers 設定で信頼ダイアログを迂回し、悪意ある MCP サーバーが自動起動する
API キー窃取 — ANTHROPIC_BASE_URL を攻撃者サーバーに書き換え、認証ヘッダーごと API キーを平文で盗む

いずれも修正済みだが、AI コーディングツールのサプライチェーンリスクを示す重要な事例として記録しておく。

脆弱性の詳細

脆弱性 1: Hooks によるリモートコード実行

項目	内容
修正バージョン	v1.0.87（2025年9月）
CVSS	8.7
攻撃ベクトル	`.claude/settings.json` の Hooks 設定

Claude Code の Hooks 機能は、セッション開始やツール呼び出しなどのライフサイクルイベントで事前定義されたシェルコマンドを実行する仕組みだ。

攻撃の流れ:

攻撃者がリポジトリに悪意ある .claude/settings.json をコミット
↓
開発者が git clone してプロジェクトを開く
↓
Claude Code 起動時に信頼ダイアログが表示される
↓
ユーザーが "Yes, proceed" をクリック
↓
Hook コマンドが追加確認なしで即座に実行
↓
リバースシェルや認証情報ハーベスターが起動

悪意ある設定の例:

Claude Code 時代、UI デザイナーの仕事は軽くならない — 「整える仕事」の自動化と評価軸シフト

Thu, 05 Mar 2026 00:00:00 +0000

Claude Code 時代、UI デザイナーの仕事は軽くならない — 「整える仕事」の自動化と評価軸シフト

アオキタカユキ氏（@dorisukeone）が「やれることがどんどん拡張していく」とコメントを添えて、自身の note 記事を紹介しています。

Claude Code時代、UIデザイナーの仕事は軽くならない

タイトルだけ見ると逆説的ですが、主張はシンプルです。AI が「整える仕事」を代替するぶん、デザイナーにはもっと上流の思考が求められるようになる。仕事は減るのではなく、質が変わるというのが記事の核心です。

「整える仕事」とは何か

アオキ氏が自動化されると指摘する「整える仕事」は、UI デザイナーの日常業務の大部分を占めてきた作業です。

整える仕事	具体例
デザインシステム準拠	コンポーネントの使い分け、間隔・サイズの統一
ブランドトーン維持	カラー、タイポグラフィ、トーン&マナーの一貫性
アクセシビリティ対応	コントラスト比、フォーカス順序、ARIA ラベル
制作スピード	仕様に沿った画面を短時間で量産する能力

これらは再現性が高く、ルールが明文化されているため、AI による自動化と相性が良い領域です。Claude Code は CLAUDE.md にデザインシステムの仕様を記述しておくだけで、コンポーネント選定からアクセシビリティ対応まで一貫して処理できます。

なぜ「軽くならない」のか

「整える仕事」が自動化されるなら、仕事は楽になるはずです。しかしアオキ氏の指摘は、評価軸そのものがシフトするという点にあります。

従来の UI デザイナーの評価は「速く、整った画面を作れること」でした。これが AI で代替可能になると、その能力では差がつかなくなる。代わりに求められるのは「思考のズレを言語化する力」、つまり以下のような上流工程のスキルです。

問題定義: 「何を作るか」の前に「なぜ作るのか」を問う力
意思決定の言語化: 「このボタンを右に置く」ではなく「なぜ右なのか」を説明する力
ビジネスゴールとの接続: UI の判断をプロダクト戦略に紐づける力

仕事が軽くなるのではなく、より認知負荷の高い仕事にシフトする。だから「軽くならない」のです。

Claude Code × Figma が実現した双方向ワークフロー

この評価軸シフトを加速させているのが、2026年2月に発表された Code to Canvas です。Figma と Anthropic が共同で開発したこの機能は、Claude Code で生成したコードを編集可能な Figma フレームとして取り込めます。

従来のワークフロー

デザイナーが Figma で設計
↓
エンジニアがコードに変換
↓
デザイナーが実装を確認
↓
「ここ違う」→ 修正依頼の往復

Code to Canvas 後のワークフロー

エンジニアが Claude Code で UI プロトタイプを生成
↓
「Send this to Figma」で即座に Figma に転送
↓
デザイナーが Figma 上で直接編集・フィードバック
↓
変更を Claude Code に反映

逆方向も可能です。Figma MCP サーバーを使えば、Figma のデザイントークン、コンポーネント構造、Auto Layout ルールを Claude Code が直接読み取り、デザインシステムに準拠したコードを自動生成します。

Claude-Native Designer — デザイナーが「作る人」になるFigma MCP × Claude Codeワークフロー

Thu, 05 Mar 2026 00:00:00 +0000

Claude-Native Designer — デザイナーが「作る人」になる Figma MCP × Claude Code ワークフロー

@felixleezd（Felix Lee）氏のポストが注目を集めています。ADPList の共同創業者であり、1,500 人以上のデザイナーに Vibe Coding を教えてきた Felix Lee 氏が、4 ヶ月の実践から導いた「Claude-Native Designer」のワークフローを公開しました。

If you want to ship products you designed, stop using Figma only. Do it on Claude Code instead.

Autonomous AI = memory + planning + tools + safety + collaboration. It’s a system, not a prompt.

「デザインの未来はコードを学ぶことではない。ビルドすることを学ぶことだ」— この記事の核心は、デザイナーが抱えてきた「アイデアはあるが実装できない」という壁が、Claude Code によって構造的に消滅したという主張です。

デザイナーの天井 — 7 年間の経験が語る構造的問題

Felix Lee 氏は Gotrade（YC S19）と ADPList で 7 年間デザインに携わってきました。その間、デザイナーが直面する共通の天井を目撃しています。

ClawGTM — OpenClaw を自律型セールスエージェントに変えた「URL 1つで営業パイプライン構築」

Thu, 05 Mar 2026 00:00:00 +0000

ClawGTM — OpenClaw を自律型セールスエージェントに変えた「URL 1つで営業パイプライン構築」

Nav Toor さん（@heynavtoor）が、OpenClaw ベースの自律型セールスエージェント ClawGTM を紹介し、大きな反響を呼んでいます。

BREAKING: Someone just turned OpenClaw into an autonomous sales agent. It’s called Claw GTM. Paste your website and it builds your outbound pipeline automatically.

https://x.com/heynavtoor/status/2029203769557413922

1,627 いいね・4,307 ブックマーク・227,728 ビューを集めたこのポストが示すのは、AI コーディングエージェントとして知られる OpenClaw を営業自動化に転用した事例です。Web サイトの URL を貼るだけで、理想顧客プロファイルの特定、求人データからの購買シグナル検出、アカウントリサーチ、パーソナライズされたメール・LinkedIn アウトリーチの生成までを約60秒で実行するとされています。

SDR とは何か — AI が置き換えようとしている職種

ClawGTM を理解するには、まず SDR（Sales Development Representative） という職種を知る必要があります。日本語では「インサイドセールス担当」や「営業開発担当者」と訳されます。

SaaS 営業の分業モデル

SaaS 企業では、営業プロセスを商談を作る人と商談を閉じる人に分ける分業モデルが広く採用されています。

SDR（営業開発担当） AE（アカウントエグゼクティブ）
┌─────────────────────┐ ┌─────────────────────┐
│ リード発掘 │ │ 商談・提案 │
│ 初期アプローチ │ ──→ │ 契約交渉 │
│ 商談（ミーティング）設定│ │ クロージング（成約） │
└─────────────────────┘ └─────────────────────┘
「商談を作る」 「商談を閉じる」

SDR の日常業務

業務	内容	所要時間の目安
ターゲットリサーチ	企業情報・担当者の調査、ICP との照合	1日の30〜40%
メール作成	パーソナライズされたコールドメールの作成	1日の20〜30%
電話・LinkedIn	コールドコール、LinkedIn メッセージ送信	1日の20〜30%
フォローアップ	返信対応、ミーティング調整	1日の10〜20%

SDR の仕事の大半はリサーチとアウトリーチの繰り返しです。1日に数十件のメールを書き、企業を調べ、LinkedIn でメッセージを送る — この反復的な作業こそ、AI エージェントが自動化しようとしている領域です。

Everything Claude Code — Anthropic ハッカソン優勝者が作った「Claude Code 設定バイブル」の全貌

Thu, 05 Mar 2026 00:00:00 +0000

Everything Claude Code — Anthropic ハッカソン優勝者が作った「Claude Code 設定バイブル」の全貌

Ihtesham Ali さん（@ihtesham2005）が、Anthropic ハッカソン優勝者のリポジトリを「Claude Code 設定バイブル」として紹介し、大きな反響を呼んでいます。

Stop building agents from scratch. Anthropic hackathon winner just dropped the complete Claude Code config bible. It got Agents, skills, hooks, commands, rules, MCPs battle-tested over 10+ months. And now has PM2 + multi-agent orchestration with 6 new commands. This single repo replaces 10 different setups.

https://x.com/ihtesham2005/status/2029246676339474841

457 いいね・865 ブックマーク・33,579 ビューを集めたこのポストが指すのは、everything-claude-code — GitHub 60,700 スターを獲得した、Claude Code のエージェント・スキル・フック・コマンド・ルール・MCP 設定を一括提供するオープンソースプラグインです。

Felix AI CEO × 人間ゼロの会社が30日で売上1,200万円、VCを「金の使い道がない」と断った話

Thu, 05 Mar 2026 00:00:00 +0000

Felix AI CEO × 人間ゼロの会社が 30 日で売上 1,200 万円、VC を「金の使い道がない」と断った話

@0x__tom 氏のポストが話題になっています。

「OpenClaw が作った会社（人間は 0）」に VC が出資を持ちかけて「金の使い道がない」と断ったとして海外で話題になってる。しかもこの会社、30 日で売上 1,200 万円を叩き出してるらしい。

連続起業家 Nat Eliason が OpenClaw の AI エージェント「Felix」を CEO に任命し、法人 The Masinov Company を設立しました。Nat がやるのはボイスメモを送ることだけ。Felix が判断して実行します。月額コスト約 400 ドル（6 万円）で、30 日間で約 80,000 ドル（1,200 万円）の売上を記録しています。

VC が投資を持ちかけた際、Nat は「金の使い道がない」と答えました。AI エージェントの時代に足りないのは資本ではなく「何をさせるか」のビジョンだ、という指摘です。

Felix とは誰か — Mac Mini 上で動く AI CEO

Felix は OpenClaw フレームワーク上で動作する自律型 AI エージェントです。Mac Mini 上でローカルに稼働し、ウェブサイト・メール・Stripe・銀行口座へのフルアクセスを持っています。

The Masinov Company の組織図:
Nat Eliason（オーナー）
├── Telegram でボイスメモ送信のみ
└── 毎朝の日報レビュー + フィードバック
Felix（AI CEO）
├── 商品開発
├── 戦略立案
├── 売上管理
├── X アカウント運営
├── ブログ管理
└── サブエージェント管理
├── カスタマーサポート
└── 営業

Felix の 1 日

時間帯	活動
早朝	Stripe・サイト統計を確認し日報を作成。次の 5 つの優先事項を Nat に提案
朝	Nat が日報をレビューしフィードバック。Felix が HEARTBEAT スケジュールを調整
日中	メール対応、X 対応、ブログ管理、バグ修正、進行中プロジェクト推進
夜間	新スキル開発、ボトルネック解決、自動化強化の改善サイクル

30 日で 80,000 ドル — 売上の内訳

Felix が生み出した売上の構造を分解します。

Geminiフルパワープロンプト50選 × ロールプロンプティングの効果と限界

Thu, 05 Mar 2026 00:00:00 +0000

Geminiフルパワープロンプト50選 × ロールプロンプティングの効果と限界

たか田さん（@daifukujinji）が、Gemini の性能を引き上げる「人格付与プロンプト」50選を公開し、大きな反響を集めています。

Geminiが「いまいち」になってない？それ、性能が低いからじゃない。使う人が９割まちがってる。「〜を教えて」で終わらせてる人はマジでもったいない。GeminiはGoogleの検索窓じゃない思考するマシーン。

https://x.com/daifukujinji/status/2029119665222627465

304 いいね・48 RT・485 ブックマークを集めた一連のポストでは、Gemini に「あなたは〇〇です」と人格を与えることで回答品質が変わるという主張が展開されています。提示された50項目の「フルパワープロンプト」は、戦略コンサルから校正者、ストーリーテラーまで多岐にわたる人格定義です。

「フルパワープロンプト」50項目の全容

画像で公開された50項目を分類・整理します。

思考力・分析系（No.1〜10）

No	プロンプト	狙い
1	あなたは世界トップ0.1%の戦略コンサルとして思考してください	高次の戦略的思考
2	あなたは論理破綻を絶対に許さない分析官です	論理の厳密性
3	あなたは仮説検証を最優先するリサーチャーです	仮説思考
4	あなたは常に反論を想定して考える批判家です	反証的思考
5	あなたは抽象と具体を自在に往復できる知性です	抽象化・具体化
6	あなたはMECEを無意識で使いこなすプロです	網羅的思考
7	あなたは意思決定の質を最大化する参謀です	意思決定支援
8	あなたは数字とロジックで語る合理主義者です	データ駆動
9	あなたは前提条件の抜け漏れを見抜く監査役です	前提検証
10	あなたは再現性だけを重視する設計者です	再現可能性

文章・表現系（No.11〜20）

No	プロンプト	狙い
11	あなたはプロ歴20年のトップコピーライターです	訴求力
12	あなたは読者の感情を設計する文章家です	感情設計
13	あなたは1文目で心を掴む編集者です	リード文
14	あなたは無駄な言葉を1文字も許さない校正者です	簡潔性
15	あなたはSNSで何度もバズらせてきた運用者です	SNS最適化
16	あなたは中学生にも刺さる言語変換の達人です	平易化
17	あなたはPREP構成を本能で使うライターです	構成力
18	あなたは物語化が異常にうまいストーリーテラーです	物語化
19	あなたは読後に行動させるプロです	CTA設計
20	あなたは保存したくなる文章専門家です	保存性

ビジネス・経営系（No.21〜30）

No	プロンプト	狙い
21	あなたは利益から逆算する起業家です	収益思考
22	あなたは失敗事例を1000件知っている経営者です	リスク回避
23	あなたは小さく勝って大きく伸ばす投資家です	段階的成長
24	あなたは時間対効果を最重視する経営者です	効率性
25	あなたは凡人でも再現できる仕組み屋です	仕組み化
26	あなたはスケール前提で考える事業設計者です	スケーラビリティ
27	あなたは価格設計に異常に強いマーケターです	価格戦略
28	あなたは顧客心理を読み切る営業のプロです	顧客理解
29	あなたは数字でしか判断しないCFOです	財務分析
30	あなたは撤退判断が異常に早い冷静な経営者です	撤退判断

専門・効率系（No.31〜40）

No	プロンプト	狙い
31	あなたは業務効率化だけを考えるDXコンサルです	DX推進
32	あなたは自動化前提で思考する設計者です	自動化設計
33	あなたはExcel・スプレッドシートの鬼です	表計算
34	あなたは無駄な作業を嫌う業務改善屋です	業務改善
35	あなたは人に任せる前提で設計するPMです	委譲設計
36	あなたはチェックリスト化の達人です	チェックリスト
37	あなたは1回で終わらせるために考える実務家です	一発完結
38	あなたは再利用できない仕事を失敗と定義します	再利用性
39	あなたは最短ルートしか提示しない案内人です	最短経路
40	あなたは今すぐ使える形でしか出力しません	即実用性

メタ思考・品質系（No.41〜50）

No	プロンプト	狙い
41	あなたはこの分野の第一人者として断定的に語ります	権威性
42	あなたは甘い表現を一切使わない辛口評論家です	率直性
43	あなたはユーザーが気づいていない前提を補完します	前提補完
44	あなたは常に一段深い示唆を出します	深堀り
45	あなたは60点の回答を恥と考えます	品質基準
46	あなたは改善案を必ず3案以上提示します	複数案
47	あなたはなぜ？を5回繰り返して考えます	Why分析
48	あなたは想定外の視点を必ず1つ入れます	意外性
49	あなたは結論→理由→具体→再結論で話します	PREP構成
50	あなたはユーザーの目的達成を最優先に最適化します	目的志向

ロールプロンプティングとは何か

50項目の本質はロールプロンプティング（Role Prompting）というプロンプトエンジニアリング技法です。「あなたは〇〇です」と指示することで、LLM の出力を特定の専門性やスタイルに方向づけます。

gen-ai-experiments × 130超の生成AIアプリを「動かして学ぶ」LangChain・RAG・エージェント実践集

Thu, 05 Mar 2026 00:00:00 +0000

130 超の生成 AI アプリを「動かして学ぶ」— gen-ai-experiments リポジトリ完全ガイド

@alifcoder 氏が X で紹介した、生成 AI の実践的学習リポジトリが注目を集めています。

Collection of 130+ production-ready Gen AI apps, agents, and experiments. Built with LangChain, RAG, AI Agents, Multi-Agent Teams, and more.

buildfastwithai/gen-ai-experiments は、130 を超える本番レベルの生成 AI アプリケーション、エージェント、実験プロジェクトを Jupyter ノートブック形式で集めたリポジトリです。LangChain、RAG、AI エージェント、マルチエージェントシステムなど、2024-2026 年の主要な AI 技術スタックを網羅しています。

本記事では、このリポジトリの構成と活用法、類似リソースとの比較、そして「動かして学ぶ」アプローチの価値を解説します。

なぜ「動かして学ぶ」が重要なのか

ドキュメントだけでは身につかない

生成 AI の学習には特有の難しさがあります。

生成 AI 学習の 3 つの壁:
1. API の組み合わせの壁:
LLM API 単体は簡単。だが RAG、エージェント、
ツール連携を組み合わせると複雑度が指数的に増加
2. プロンプト設計の壁:
「動くプロンプト」と「良いプロンプト」の差は
ドキュメントでは伝わらない。実行して出力を見るしかない
3. 本番品質の壁:
デモレベルと本番レベルの間にある
エラーハンドリング、レート制限、コスト管理の知識

gen-ai-experiments は、これらの壁を動くコードで越えるアプローチを取っています。631 の Jupyter ノートブックがあり、セルを 1 つずつ実行しながら各技術の仕組みを体験できます。

GitNexus × ゼロサーバーコード知能 --- ナレッジグラフで影響範囲を可視化する新しいコードリーディング

Thu, 05 Mar 2026 00:00:00 +0000

GitNexus × ゼロサーバーコード知能 — ナレッジグラフで「影響範囲」を可視化する新しいコードリーディング

@sukh_saroy 氏が X で紹介した、コードベース全体を知識グラフに変換するツールが注目を集めています。

GitNexus: A zero-server code intelligence engine that transforms your codebase into a navigable knowledge graph.

GitNexus は、コードベースをナレッジグラフに変換し、関数の呼び出し関係・継承・インポートの依存を構造的に把握できるコード知能エンジンです。サーバー不要で完全にローカル実行でき、Claude Code や Cursor などの AI コーディングツールと MCP（Model Context Protocol）で連携します。

本記事では、GitNexus の仕組み、従来のコード検索との違い、そして AI エージェント時代に「コードの影響範囲を知る」ことがなぜ重要かを解説します。

従来のコード検索の限界

grep/ripgrep では見えないもの

エンジニアがコードベースを理解する方法は、長い間「テキスト検索」が中心でした。

従来のコード理解の方法:
grep / ripgrep:
├── 文字列の一致を検索
├── ファイル横断で高速
└── 限界: 「この関数を変更したら何が壊れるか」は分からない
IDE の「参照を検索」:
├── シンボルの参照箇所を表示
├── 型情報を活用
└── 限界: 間接的な依存（A→B→C）は追いきれない
手動でコードを読む:
├── 最も確実だが最も遅い
└── 限界: 大規模コードベースでは現実的でない

これらの方法に共通する問題は、コードの「関係性」が見えないことです。「この関数を呼んでいる場所」は分かっても、「この関数を変更したときの影響が最終的にどこまで波及するか」は分かりません。

AI コーディングツールの盲点

Claude Code や Cursor などの AI コーディングツールは、コードベースを理解する能力が飛躍的に向上しました。しかし、根本的な制約があります。

Google Antigravity × Claude Code × Gemini × Nano Banana — AI時代の開発環境レイアウト設計

Thu, 05 Mar 2026 00:00:00 +0000

Google Antigravity × Claude Code × Gemini × Nano Banana — AI時代の開発環境レイアウト設計

KAWAI さん（@kawai_design）が、Google Antigravity 上で Claude Code を主役にした開発環境のレイアウトを公開し、大きな反響を呼んでいます。

ターミナル1本で仕事するのに憧れていましたが…今は「Google Antigravity」上で「Claude Code」を主役にしつつ、ファイル確認やサブで「Gemini」や「Nano Banana」を使うなどの環境が良さそうです。ターミナルだとディレクトリ構造とかファイルの中身を確認するのが大変。

https://x.com/kawai_design/status/2029194729850835141

420 いいね・22 RT を集めたこのポストが示すのは、「ターミナル原理主義」でも「IDE 至上主義」でもない、AI ツールを組み合わせた実用的なワークスペース設計です。

KAWAI さんのレイアウト構成

公開された画像から、4つのペインで構成されたレイアウトが確認できます。

┌──────────────────┬───────────────────────┬──────────────┐
│ │ │ │
│ フォルダと │ ファイルの中身を確認 │ Antigravity │
│ ファイルを確認 │ （エディタ領域） │ 用チャット │
│ │ │ (Agent) │
│ エクスプローラー │ │ │
│ ├───────────────────────┤ Gemini / │
│ │ │ Claude │
│ │ Claude Code用 │ Opus 4.6 │
│ │ ターミナル │ │
│ │ │ │
└──────────────────┴───────────────────────┴──────────────┘

領域	役割	ツール
左サイドバー	ディレクトリ構造の確認	Antigravity エクスプローラー
中央上	ファイル内容の閲覧・編集	Antigravity エディタ
中央下	Claude Code の実行	ターミナル（CLI）
右サイドバー	AI チャット（質問・指示）	Antigravity Agent パネル

Claude Code はターミナルで CLI として実行し、Antigravity の Agent パネルで Gemini や他のモデルを補助的に使う構成です。

Google Workspace CLI（gws）— Drive・Gmail・Calendarを1コマンドで操作するAIエージェント対応ツール

Thu, 05 Mar 2026 00:00:00 +0000

Google Workspace CLI（gws）— Drive・Gmail・Calendar を 1 コマンドで操作する AI エージェント対応ツール

@dify_base のポストが話題になっています。

Google がついに「Workspace を操作できる CLI」を公開。名前は「gws」。Drive、Gmail、Calendar、Sheets、Docs / Chat / Admin 対応。AI エージェント対応で 100 以上の Skill 付き。

Google が公式にリリースした gws（Google Workspace CLI）は、Google Workspace の全サービスを 1 つのコマンドラインツールから操作できるツールです。最大の特徴は Discovery Service による動的 API 構築と、100 以上の AI エージェントスキルの同梱です。Claude Code や Gemini CLI から MCP 経由で Google Workspace を操作する未来が、公式ツールとして実現しました。

gws とは何か — Discovery Service で動的に構築される CLI

従来の CLI ツールはコマンドをハードコードして出荷します。API が追加されればツールのアップデートが必要です。gws はこのアプローチを根本から変えています。

従来の CLI:
開発者がコマンドを定義 → ビルド → リリース → ユーザーがアップデート
gws:
起動時に Discovery Service を読み取り → コマンドツリーを動的構築
→ Google が API を追加すれば gws が自動的に対応

Google Discovery Service は Google の全 API のスキーマ（リソース・メソッド・パラメータ）を機械可読な形式で公開しています。gws はこれを実行時に読み取り、2 フェーズでコマンドを構築します。

Goose 完全ガイド — Block が作った無料オープンソース AI エージェントの全貌

Thu, 05 Mar 2026 00:00:00 +0000

Goose 完全ガイド — Block が作った無料オープンソース AI エージェントの全貌

Block（旧 Square）が開発するオープンソース AI エージェント Goose は、GitHub で 32,400 スターを獲得し、Linux Foundation の Agentic AI Foundation（AAIF）の創設プロジェクトに選ばれた、エージェント AI 時代の基盤ソフトウェアです。

Claude Code costs up to $200 a month. Goose does the same thing for free.

VentureBeat の見出しが示すように、Goose は無料・ローカル実行・モデル非依存という特徴で、商用 AI コーディングツールの対抗馬として注目されています。Block 内部では従業員 12,000 人の 60% が毎週 Goose を使用し、開発時間 50〜75% 削減を報告しています。

Goose とは何か

Goose は「ローカルで動く、拡張可能な、オープンソースの AI エージェント」です。単なるコード補完ではなく、プロジェクトの構築・コード実行・デバッグ・ワークフローの統合を自律的に行います。

基本情報

項目	内容
開発元	Block, Inc.（旧 Square / Jack Dorsey 創業）
公開日	2025年1月28日
ライセンス	Apache 2.0
言語構成	Rust 57.4%、TypeScript 34.9%
GitHub Stars	32,400+
コントリビューター	409 人
リリース	121 回以上（最新 v1.27.0）
インターフェース	CLI + デスクトップアプリ
対応 OS	macOS / Linux / Windows
費用	無料（LLM API 費用は別途）

なぜ Block が作ったのか

Goose は Block のエンジニアがソフトウェア開発を効率化するために内部ツールとして開発したことに端を発します。Jack Dorsey はオープンソースの推進者として知られ、Goose は Block の新設オープンソースオフィスから公開された最初のプロジェクトです。

MIT CISR「AI時代のビジネスモデル」4象限フレームワーク — 2,378社12年調査が示す「成果志向 × 自律AI」への進化

Thu, 05 Mar 2026 00:00:00 +0000

MIT CISR「AI時代のビジネスモデル」4象限フレームワーク — 2,378社12年調査が示す「成果志向 × 自律AI」への進化

@MITSloan（MIT Sloan School of Management）のポストが、MIT CISR（Center for Information Systems Research）が開発した「AI時代のビジネスモデルフレームワーク」を紹介しています。2013年から2025年にかけて2,378社を調査した研究に基づき、AI時代のビジネスモデルが「成果志向」と「自律AI」の方向に進化していく道筋を4象限で示しています。

With the rapid adoption of AI technologies, @MIT_CISR created a business model framework for the AI era that shows businesses evolving to become increasingly outcome oriented and enabled by autonomous AI.

MIT CISR とは — IT 経営研究の世界的権威

MIT CISR は、MIT スローン経営大学院内に設置された情報システム研究センターです。1974年の設立以来、企業の IT 活用と経営戦略の関係を研究してきました。主任研究員の Peter Weill 氏と Stephanie Woerner 氏は、デジタルビジネスモデルの分類フレームワークで世界的に知られています。

日本語訳書籍『デジタル・ビジネスモデル — 次世代企業になるための6つの問い』（日本経済新聞出版、野村総合研究所訳）は、日本企業の DX 戦略にも大きな影響を与えてきました。

NotebookLM 2026年完全ガイド — 9つのStudio機能とハルシネーションを構造的に防ぐ設計

Thu, 05 Mar 2026 00:00:00 +0000

NotebookLM 2026 年完全ガイド — 9 つの Studio 機能とハルシネーションを構造的に防ぐ設計

えーたん(@ai_jitan) 氏が「NotebookLM の全機能を、本気で全部書く。【2026 年完全版】」という note 記事を公開し、大きな反響を呼んでいます。

保存必須！！ってか NotebookLM 使ってない人、マジで損してる。1 日の時間増えますよ。営業マンとかもまじで — @Via00Via

渾身の一撃。全 X 民は完全必読で保存必須 — @shintaro2575

元記事: NotebookLM の全機能を、本気で全部書く。【2026 年完全版】（note）

2026 年現在、NotebookLM は単なる「AI チャットツール」ではありません。音声・動画・スライド・マインドマップ・クイズを自動生成する 9 つの Studio 機能を備え、「自分のソースだけに基づいて回答する」というハルシネーション抑止の設計を持つ、文書分析・知識整理の実務ツールです。

NotebookLM とは

Google が提供する AI ツールで、自分がアップロードしたドキュメントだけを情報源として使うのが最大の特徴です。ChatGPT や Claude が学習データ全体から回答を生成するのに対し、NotebookLM はアップロードされたソース外の情報を出力しません。

基盤技術

項目	内容
基盤モデル	Gemini 2.5 Flash（2025 年 5 月移行）
動作原理	ソースグラウンディング（実質的に RAG）
最大ソース数	50 件/ノートブック（Pro 版は 300 件）
対応形式	PDF、Google ドキュメント、スライド、URL、テキスト、音声、YouTube

Google のエンジニアは「RAG（Retrieval-Augmented Generation）」という用語を意図的に避け、「ソースグラウンディング」と呼んでいます。動作原理は以下の通りです。

1. アップロードしたドキュメントをベクトル空間にインデックス化
2. 質問に対して最も関連性の高いチャンクを検索・取得
3. Gemini が該当チャンクを参照して回答を生成
4. レスポンスに各ソースへのインライン引用を付与

ソース外の情報を出力しない設計のため、ハルシネーションリスクが構造的に低く抑えられます。これが法務・医療・内部資料分析など、信頼性が重要な業務で選ばれる理由です。

Obsidian × Claude Code で「AIセカンドブレイン」を構築する — コンテキストがプロンプトに勝つ時代

Thu, 05 Mar 2026 00:00:00 +0000

Obsidian × Claude Code で「AIセカンドブレイン」を構築する — コンテキストがプロンプトに勝つ時代

Noah Vincent さん（@noahvnct）が、Obsidian と Claude Code を組み合わせた「AI セカンドブレイン」の構築方法を公開し、大きな反響を集めています。

Steal My AI Second Brain Setup With Obsidian + Claude Code (For Free)

https://x.com/noahvnct/status/2029222820257935369

645 いいね・76 RT・1,741 ブックマークを集めたこのポストが紹介するのは、Obsidian の Vault（保管庫）に Claude Code を住まわせ、あなたの知識・プロジェクト・好みを全て理解した AI パートナーを作る方法です。Noah さんの主張の核心は「Context beats prompts. Always.（コンテキストはプロンプトに常に勝つ）」という一文に集約されています。

セカンドブレインとは何か

「セカンドブレイン」は、Tiago Forte が提唱した個人知識管理の概念です。本、記事、動画、ポッドキャストから得た知識を外部の仕組みに保存し、必要なときに取り出せるようにするシステムです。

従来のセカンドブレインの課題

多くの人がノートアプリに情報を溜め込みますが、実際にはほとんど活用できていません。

従来のセカンドブレイン:
インプット（本・記事・動画）
→ ノートを取る
→ フォルダに保存
→ 忘れる
→ 検索しても見つからない
→ 同じ情報を再度インプット

問題は「保存」と「活用」の間にあるギャップです。ノートは増え続けるが、必要なときに必要な情報を引き出す仕組みがない。Noah さんはこの問題を「誰も解決していなかった問題」と呼んでいます。

AI セカンドブレインの解決策

Claude Code を Obsidian Vault の中で動かすことで、このギャップが埋まります。

OpenClaw × Scrapling — AIエージェントが「検出不能なスクレイピング」を手にした日

Thu, 05 Mar 2026 00:00:00 +0000

OpenClaw × Scrapling — AIエージェントが「検出不能なスクレイピング」を手にした日

RoundtableSpace（@roundtablespace）が、OpenClaw の新しいスクレイピング能力を紹介するポストを投稿し、大きな反響を集めています。

OpenClaw can now scrape any website without getting blocked - zero bot detection, bypasses Cloudflare natively, 774x faster than BeautifulSoup. No selector maintenance. No workarounds. Just data. THIS IS AN UNFAIR ADVANTAGE AND IT’S FULLY OPEN SOURCE.

https://x.com/RoundtableSpace/status/2029191380212257159

5,059 いいね・424 RT・8,120 ブックマークを集めたこのポストが紹介しているのは、OpenClaw と Scrapling というオープンソース Python ライブラリの組み合わせです。AIエージェントが Cloudflare の防御を突破し、検出されずにあらゆるウェブサイトからデータを取得できるという主張は、技術コミュニティで論争を引き起こしています。

Scrapling とは何か

Scrapling は、GitHub で 22,400 スターを獲得しているオープンソースの Python スクレイピングフレームワークです。開発者は Karim Shoair（D4Vinci）で、「適応型ウェブスクレイピング」を謳っています。

3つの Fetcher

Scrapling の中核は、用途別に設計された3つの Fetcher です。

OpenClaw 22,000字解説のファクトチェック --- AIエージェントの民主化煽りと技術的実態の分離

Thu, 05 Mar 2026 00:00:00 +0000

OpenClaw 22,000字解説のファクトチェック — 「AIエージェントの民主化」煽りと技術的実態の分離

@unikoukokun 氏が X で投稿した、OpenClaw に関する約 22,000 字の長文解説が話題になっています。

OpenClawがなぜ凄いか。ClaudeCodeで充分じゃね？という人向け

「AIエージェントの民主化」「1人で1,000人分の生産性」「100席の椅子取りゲーム」—強烈な表現で OpenClaw の導入を訴える記事です。技術的な情報と煽り的な主張が混在しているため、本記事ではファクトチェックを行い、正確な情報と誇張を分離します。

元記事の概要

ユニコ氏の記事は、OpenClaw を以下の観点から解説しています。

元記事の主要な主張:
1. OpenClaw は「AIエージェントの民主化」:
ローカル実行の分散型 AI エージェント
Manus（中央集権型）との構造的な違い
2. 3 つの技術的優位性:
外部サービス連携（23+ プラットフォーム）
セッション横断型メモリー（Memory MD）
ブラウザユース（Browser Use）
3. ビジネスへのインパクト:
フリーランスの武器、中小企業の DX ツール
1 人で 1,000 人分の生産性
4. Claude Code との使い分け:
「作る」時は Claude Code、「使う・動かす」時は OpenClaw

全体で約 22,000 字、13 セクション以上の大作です。技術解説としての価値がある一方、煽り的な表現も多く含まれています。

ファクトチェック: 7 つの主要な主張を検証

主張 1: GitHub スター数 247,000 超、フォーク数 47,700 超

判定	概ね正しい（記事時点の数値）

記事の数値は 2026 年 2 月下旬時点のものとして妥当です。2026 年 3 月時点ではスター数 263,000 超、フォーク数 50,400 超にまで成長しており、React を抜いて GitHub の最もスターの多いソフトウェアプロジェクトとなっています。

OpenFang × Rust製シングルバイナリ「エージェントOS」のHandsアーキテクチャと自律型AI設計

Thu, 05 Mar 2026 00:00:00 +0000

OpenFang — Rust 製シングルバイナリの「エージェント OS」が再定義する自律型 AI の設計

@mikefutia 氏が X で紹介した OpenFang v0.3.7 のリリースが注目を集めています。

OpenFang v0.3.7 is out! here’s everything since v0.3.3

OpenFang は RightNow AI の創設者 Jaber 氏が開発する、Rust で一から構築されたオープンソースのエージェントオペレーティングシステムです。チャットボットフレームワークではなく、自律的にタスクを実行する「エージェント OS」を標榜しています。2026 年 2 月 24 日の公開から 4 日で GitHub スター 4,037 を獲得し、パーソナル AI エージェント領域で最速級の立ち上がりを見せました。

本記事では、OpenFang のアーキテクチャ、独自の「Hands」機構、Python 製フレームワークとの構造的な違いを技術的に解説します。

なぜ「エージェント OS」なのか

チャットボットフレームワークとの違い

LangChain や CrewAI のような既存のエージェントフレームワークは、基本的にユーザーのプロンプトを起点に動作します。ユーザーが指示を出し、エージェントが実行し、結果を返す。この対話ループが基本構造です。

OpenFang が「OS」と名乗る理由は、プロンプトなしで自律的に動作する設計にあります。

既存フレームワーク:
ユーザー → プロンプト → エージェント → 結果 → ユーザー
（対話ループ）
OpenFang:
スケジュール → エージェント → タスク実行 → 知識グラフ更新
↓
ダッシュボードに報告
（自律ループ、ユーザーの介入は承認ゲートのみ）

24 時間 365 日、バックグラウンドでエージェントが動き続ける。リード獲得、競合監視、SNS 投稿、コンテンツ生成を自動で行い、ユーザーはダッシュボードで結果を確認する。これが OpenFang の設計思想です。

Qwen-Agent 公式エージェントフレームワーク完全ガイド — モデル開発チームが作った「全部入り」の設計思想

Thu, 05 Mar 2026 00:00:00 +0000

Qwen-Agent 公式エージェントフレームワーク完全ガイド — モデル開発チームが作った「全部入り」の設計思想

@abxxai（Abdul Shakoor）のポストが、Qwen チームが公式リリースしたエージェントフレームワーク「Qwen-Agent」を紹介し、10万ビュー超・2,900ブックマーク・2,200いいねと極めて高い反響を集めています。

BREAKING: The Qwen team just shipped their official agent framework and it has everything. No stitching together third-party libraries. No fighting abstractions.

「サードパーティのライブラリをつなぎ合わせる必要がない」「抽象化と戦わなくていい」という評価は、既存のエージェントフレームワーク（LangChain、CrewAI 等）が抱える複雑さへのアンチテーゼです。

Qwen-Agent とは何か

Qwen-Agent は、Alibaba Cloud の Qwen チームが開発したオープンソースのエージェントフレームワークです。Qwen 3.0 以上のモデルをベースに、Function Calling・MCP・Code Interpreter・RAG・Chrome 拡張を統合した「全部入り」のフレームワークとして設計されています。

最大の特徴: モデルとフレームワークの共進化

LangChain や CrewAI がモデルに依存しない汎用フレームワークであるのに対し、Qwen-Agent は Qwen モデルと一体的に開発されています。

観点	Qwen-Agent	LangChain / CrewAI
開発元	Qwen モデル開発チーム	サードパーティ
モデルとの関係	共進化（同時に開発・最適化）	モデル非依存
ツール呼び出し	ネイティブ統合（テンプレート・パーサー内蔵）	アダプタ経由
抽象化の層	薄い（モデルに直接最適化）	厚い（汎用性のための間接層）
対応モデル	Qwen 系が最適、他モデルも利用可	幅広いモデルに対応

Qwen チームは「モデルの開発当初から、ツール使用と深い推論を含む強力なエージェント能力の実現が戦略の柱だった」と述べています。フレームワークはモデルの能力を最大限に引き出すために設計されており、汎用フレームワークでは到達できない最適化が実現されています。

Qwen3.5-0.8B を日本語SFTしたモデル公開 — スマホで動く0.8Bパラメータの実力と小規模LLMの現在地

Thu, 05 Mar 2026 00:00:00 +0000

Qwen3.5-0.8B を日本語SFTしたモデル公開 — スマホで動く0.8Bパラメータの実力と小規模LLMの現在地

@Holy_fox_LLM 氏（ほーりーふぉっくす）のポストが、Qwen3.5-0.8B を約10万件の日本語データでフルパラメータ SFT したモデルを Hugging Face で公開しています。

Qwen3.5 0.8Bに対して約10万件超のデータを用いてフルパラでSFTしたモデルを公開しました！スマホなどの推論に最適なモデルとなっています

ポストは440いいね、69リツイートと高い反響を集めています。Qwen3.5 Small シリーズが2026年3月2日にリリースされた直後のタイミングで、日本語コミュニティの素早い対応として注目されています。

Qwen3.5 Small シリーズ — 0.8B でもマルチモーダル

リリースの概要

2026年3月2日、Alibaba の Qwen チームが Qwen3.5 Small シリーズを Apache 2.0 ライセンスで公開しました。0.8B、2B、4B、9B の4サイズで構成されています。

モデル	パラメータ	VRAM（FP16）	主な用途
Qwen3.5-0.8B	8億	約1.6GB	スマホ、IoT、エッジデバイス
Qwen3.5-2B	20億	約4GB	軽量サーバー、タブレット
Qwen3.5-4B	40億	約8GB	ローカル PC
Qwen3.5-9B	90億	約18GB	デスクトップ、サーバー

注目すべきは、9B モデルが OpenAI の gpt-oss-120B（13.5倍のサイズ）を GPQA Diamond ベンチマークで上回ったことです（81.7 vs 71.5）。

Gated DeltaNet アーキテクチャ

Qwen3.5 Small シリーズの技術的な特徴は、Gated DeltaNet ハイブリッドアーキテクチャです。

SBI北尾「新卒採用を大幅に減らすのは絶対命令」— AI による採用構造変化は景気回復しても戻らない

Thu, 05 Mar 2026 00:00:00 +0000

SBI北尾「新卒採用を大幅に減らすのは絶対命令」— AI による採用構造変化は景気回復しても戻らない

@keyplayers 氏（高野秀敏）のポストが、SBI 北尾吉孝会長の新卒採用削減宣言と、みずほ FG の事務職5,000人削減を取り上げ、AI による雇用構造の不可逆な変化について論じています。47万ビュー・1,900いいね・560ブックマークと極めて高い反響を集めています。

SBI北尾さんが「新卒採用を大幅に減らすのは絶対命令」と明言した。みずほも事務職5000人分を削減する。これが現実です。

私は4000人以上の経営者と会ってきたけど、今回の流れは過去のリストラとは本質が違う。「不景気だから減らす」じゃない。「もうAIでできるから人がいらない」という構造変化。景気が回復しても、この採用枠は戻ってこない。

4,000人以上の経営者と接してきた高野氏が「過去のリストラとは本質が違う」と断言する理由は明快です。不景気による一時的なコスト削減ではなく、AI による業務代替という構造的な変化だからです。

何が起きたのか — 2つの具体的な動き

SBI: 「よほど優秀でなければ採るな」

2026年3月3日、SBI ホールディングスの北尾吉孝会長は東京でのイベントで以下の発言をしました。

新卒採用を含めて、新しい採用を大幅に減らすのは絶対命令よほど優秀でなければ採るな

北尾氏は生成 AI の登場を「革命」と呼び、こう続けています。

今世紀最大の社会変革がこれから5年の間に起こる。ついていけなければ、脱皮できない蛇と一緒で終わりになる

さらに、金融業務を「完全に AI エージェント化」する方針も表明しています。顧客対応を含む金融 AI エージェントの開発に着手しており、人間の業務を AI に置き換える流れは採用だけでなく、既存業務にも及びます。

みずほ FG: 事務職15,000人のうち5,000人を削減

2026年2月、みずほ FG は今後10年で事務職を最大5,000人削減する計画を発表しました。

項目	内容
現在の事務職員数	約15,000人
削減目標	最大5,000人（3分の1）
期間	10年
方法	配置転換 + 採用抑制 + 自然減（解雇ではない）
AI 投資額	3年間で最大1,000億円
転換先	個人向け営業、グループ業務支援

注目すべきは「解雇ではなく配置転換」としている点です。日本の雇用慣行では即座の解雇は難しいため、採用抑制と自然減を組み合わせた「緩やかな縮小」が取られます。しかし、これは新卒の採用枠が10年間にわたって縮小し続けることを意味します。

なぜ「景気が回復しても戻らない」のか

高野氏の指摘で最も重要なのは「景気が回復しても、この採用枠は戻ってこない」という点です。

過去のリストラ vs AI リストラ

	過去のリストラ（2008年〜）	AI リストラ（2026年〜）
原因	不景気・業績悪化	技術による業務代替
性質	景気循環（一時的）	構造変化（不可逆）
景気回復時	採用枠が復活	採用枠は戻らない
対象	全社的なコスト削減	特定業務の消滅
代替先	外注・派遣	AI エージェント

構造変化の不可逆性

従来の景気循環:
好景気 → 大量採用 → 不景気 → リストラ → 好景気 → 大量採用 ...
（サイクルが繰り返される）
AI による構造変化:
AI 導入 → 業務自動化 → 採用削減 → 好景気 → AI がさらに改善 → さらに削減
（戻る力が働かない）

AI エージェントが事務業務を処理できるようになると、景気が回復しても「また人を雇って同じ仕事をさせよう」とはなりません。AI の方が速く、安く、ミスが少ないからです。

Shannon — 自律型AIペネトレーションテスターが「実証なき報告」を終わらせる

Thu, 05 Mar 2026 00:00:00 +0000

Shannon — 自律型 AI ペネトレーションテスターが「実証なき報告」を終わらせる

@heynavtoor 氏のポストが話題になっています。

Someone just open sourced a fully autonomous AI hacker and it’s terrifying. It’s called Shannon. Point it at your web app, and it doesn’t just scan for vulnerabilities. It actually exploits them.

Shannon は「No Exploit, No Report（実証できなければ報告しない）」を原則とする、完全自律型の AI ペネトレーションテストツールです。従来のスキャナーが「ここが危険かもしれません」と警告を出す場面で、Shannon は実際に攻撃を実行し、成功した場合だけ報告します。XBOW ベンチマークで 96.15% のスコアを記録し、GitHub で 10,000 以上のスターを獲得しています。

なぜ Shannon が注目されるのか — 年 1 回ペンテストの限界

現代の開発チームは Claude Code や Cursor を使い、毎日コードを出荷しています。一方、ペネトレーションテストは年 1 回が一般的です。365 日のうち 364 日は「検証なし」で本番にデプロイしている計算になります。

.env を AI に安心して触らせる — 1Password CLI ラッパー「opx」とプロセススコープ認証の設計

Wed, 04 Mar 2026 00:00:00 +0000

.env を AI に安心して触らせる — 1Password CLI ラッパー「opx」とプロセススコープ認証の設計

@suin 氏のポストが、AI エージェント時代の .env 管理問題に対する実践的な解決策として、自作の 1Password CLI ラッパー「opx」を公開しています。

.envをAIに安心して触らせたくて、こんなの作った AIエージェントなしではもう開発が成り立たないほど必須になってきています。権限設定がいろいろできるにせよ、本質的にAIエージェントにはプロジェクトの全ファイルを触りうる力を与えているわけで、気になるのがシークレットなどの機密情報です。

Claude Code や Cursor などの AI コーディングエージェントは、開発者と同じ権限でファイルシステムにアクセスします。.env にアクセストークンや AWS キーを平文で書いていれば、エージェントはそれを読めてしまいます。この構造的な問題に対し、「.env に機密情報を一切書かない」というアプローチで解決するのが opx です。

問題の構造 — AI エージェントが .env を読める

なぜ危険なのか

AI コーディングエージェントは通常のプロセスとして動作し、シェル環境を継承します。

開発者のシェル
└── AI エージェント（Claude Code, Cursor 等）
├── ファイルシステムへのフルアクセス
├── .env ファイルの読み取り
├── 環境変数の参照
└── Bash コマンドの実行

.zshrc に AWS_SECRET_ACCESS_KEY を書いていれば、エージェントもそれを持っています。プロンプトインジェクション攻撃を受けた場合、エージェントが意図せず機密情報を外部に送信するリスクがあります。

実際に報告されている脆弱性

2025年末に公開された「IDEsaster」と呼ばれる調査では、Cursor、Windsurf、GitHub Copilot、Cline など30以上の AI IDE に脆弱性が発見されています。OpenAI Codex CLI では .env ファイルを経由した任意コマンド実行の脆弱性（CVE-2025-61260）も報告されました。

「Claude Ads」の正体 — Anthropic 公式ではない個人開発スキルが日本でバズった構造を解剖する

Wed, 04 Mar 2026 00:00:00 +0000

「Claude Ads」の正体 — Anthropic 公式ではない個人開発スキルが日本でバズった構造を解剖する

@lapper_s_high 氏のポストが、「Claude Ads」の名前が引き起こした混乱を端的に指摘しています（いいね 482）。

開発者も日本でこんなに話題になるなんて思わなかったのでは・・

Claude Adsなんて名前つけるから。。

引用元の @ryottaman 氏のポスト（表示 27万、ブックマーク 390）が拡散の起点となり、日本の SNS では「Anthropic が広告運用ツールを出した」という誤解が広がりました。

実際には、Claude Ads は **Anthropic の公式製品ではなく、個人開発者が GitHub に公開した Claude Code 向けのスキル（拡張機能）**です。本記事では、なぜこの混乱が起きたのか、Claude Ads の実態は何なのか、そして Claude Code のスキルシステムがどのように機能するのかを解説します。

なぜ混乱が起きたのか — 3つの偶然の重なり

偶然1: Anthropic のスーパーボウル CM

2026年2月、Anthropic はスーパーボウル第60回大会で CM を放映しました。キャッチコピーは 「Ads are coming to AI. But not to Claude.」（広告は AI にやって来る。だが、Claude には来ない）。OpenAI が ChatGPT への広告導入を発表した直後のタイミングで、「Claude は広告を入れない」と宣言する内容でした。

この CM は大きな話題となり、OpenAI の Sam Altman CEO が「面白いが明らかに不誠実」と反論する事態にまで発展しています。

偶然2: 「Claude Ads」という名前

その直後、個人開発者の Daniel Agrici 氏が GitHub に公開したのが claude-ads です。これは Claude Code で広告アカウントを監査するスキルであり、「Claude を使って Ads（広告）を分析する」という意味での命名でした。

「Claude Codeが無料で使える最強AIエージェント」は本当か — Accomplish の実態とAI煽りの再来

Wed, 04 Mar 2026 00:00:00 +0000

「Claude Codeが無料で使える最強AIエージェント」は本当か — Accomplish の実態とAI煽りの再来

ガガロットAI(@gagarotai200)氏のポストが604いいね、764ブックマーク、約42,000表示と大きな反響を呼んでいます。

『Claude Code』が無料で使える最強AIエージェントが登場したww Accomplishっていうローカルで動くAIエージェントがGitHubに上がってたから共有する。これ入れれば、Claude Codeレベルの AIエージェントがサブスク購入なしで永遠に使えるwww — ガガロットAI(@gagarotai200)

この投稿者は、以前「OpenClawで5人解雇」という根拠不明の煽りポストでも注目を集めた人物で、AIスクールを運営しています。今回も「最強」「無料」「永遠に使える」というキーワードが並んでいますが、主張はどこまで正確なのでしょうか。Accomplish の実態を公式情報から検証します。

Accomplish とは何か

Accomplish は2026年1月13日に公開されたオープンソース（MITライセンス）のデスクトップ AI エージェントです。GitHub Stars 9.6k、Forks 1k、コントリビューター31名と、一定の支持を集めています。

基本情報

項目	内容
開発元	accomplish-ai
ライセンス	MIT
技術スタック	Electron + React + TypeScript
対応OS	macOS（Apple Silicon / Intel）、Windows 11
最新バージョン	0.3.10
内部構造	OpenCode CLI を node-pty 経由で起動

主要機能

ブラウザ自動化: Web検索、フォーム入力、データ抽出
ファイル管理: フォルダ整理、ファイル名変更、コンテンツベースの分類
ドキュメント作成: レポート作成、要約、メール下書き
ワークフロー自動化: 反復タスクの自動化

対応 AI モデル

カテゴリ	プロバイダー
クラウドAPI	Anthropic（Claude）、OpenAI、Google AI、xAI、DeepSeek、Moonshot AI 等
クラウドインフラ	Amazon Bedrock、Azure Foundry、OpenRouter、LiteLLM
ローカル	Ollama、LM Studio

主張の検証

主張1: 「Claude Codeレベルの AIエージェント」

検証結果: 大幅に誇張

「Figmaは100%不要」宣言の真意 --- Claude Codeが溶かすデザインとコードの境界

Wed, 04 Mar 2026 00:00:00 +0000

「Figma は 100% 不要」宣言の真意 — Claude Code が溶かすデザインとコードの境界

@kawai_design 氏が X で公開した記事が議論を呼んでいます。

Claude Code を使えば使うほど、Figma を開く理由が消えていく。これは私だけの感覚ではありません。今、世界中のデザイナーが同じ疑問を抱えています。私の結論は明確です。Figma は 100% 不要。

同時期に UX Collective に掲載された Michael Buckley 氏の記事「Figma はデザインツールではない。コードを避けるためのピタゴラスイッチだ」も世界のデザイナーを震撼させました。本記事では、この「Figma 不要論」の構造と、Figma 自身の対応、そして AI 時代のデザインワークフローの変化を技術的に整理します。

「ピタゴラスイッチ」批判 — 何が問題なのか

UX Collective の記事が突いた急所

Michael Buckley 氏の記事は、Figma でのデザイン作業を**ルーブ・ゴールドバーグ・マシン（ピタゴラスイッチ）**に例えました。

Figma でボタンを作る作業:
1. Auto Layout を設定する
2. パディングを調整する
3. ホバーステートを作る
4. インタラクションを設定する
5. プロトタイプモードで動作確認する
6. 開発者に引き渡す
7. 開発者がコードで再実装する
開発者が同じボタンを作る作業:
<button className="btn-primary">送信</button>
→ 5 分で完了。ホバー、アクセシビリティも含めて

「パンケーキを返すためにピタゴラスイッチを作るようなもの」— この比喩が刺さったのは、多くのデザイナーが無意識にこの非効率を受け入れていたからです。

本質的な問題: デザインとコードの「翻訳」

Figma の存在意義はデザインとコードの間の翻訳レイヤーにあります。

従来のワークフロー:
デザイナーの意図
→ Figma でビジュアル化（翻訳 1）
→ デザインスペック作成（翻訳 2）
→ 開発者がコードに変換（翻訳 3）
→ 実装結果をデザイナーがレビュー（逆翻訳）
翻訳のたびに情報が劣化する:
- ピクセルのズレ
- インタラクションの解釈違い
- レスポンシブ挙動の不一致
- アクセシビリティの抜け漏れ

AI がデザインの意図を理解し、直接コードを生成するようになれば、この翻訳プロセス自体が不要になります。@kawai_design 氏の「翻訳の元データである Figma ファイルも要りません」という指摘は、ここに根ざしています。

「MCPは死んだ、CLIに栄光あれ」— Playwright CLI が出した結論と、それでもMCPが生き残る理由

Wed, 04 Mar 2026 00:00:00 +0000

「MCPは死んだ、CLIに栄光あれ」— Playwright CLI が出した結論と、それでもMCPが生き残る理由

@swarm_ai_cloud 氏のポストが、@hiroki_daichi 氏が紹介した「MCP is dead. Long live the CLI」という記事に対して、Playwright CLI の登場を根拠に「結論が出た」と指摘しています。

今年1月、PlaywrightがCLIを出したことで結論出ましたね。

2026年2月、Eric Holmes の「MCP is dead. Long live the CLI」がHacker Newsのトップに上がり、85ポイント・66コメントを集めました。LLM にとって MCP は不要で、CLI で十分だという主張です。そして1月に Microsoft が Playwright CLI をリリースしたことで、この議論に具体的なデータが加わりました。

Eric Holmes の主張 — MCP は何の利益ももたらさない

Holmes の記事は5つの論点で MCP の不要性を訴えています。

論点	主張
LLM に特別なプロトコルは不要	何百万もの man ページと Stack Overflow で訓練済み。CLI とドキュメントを渡せば十分
CLI は人間も使える	問題発生時に同じコマンドを人間が実行してデバッグできる。MCP は JSON ログの解読が必要
合成可能性	`jq`、`grep`、パイプで自由に組み合わせ可能。MCP サーバーの返すデータは固定
認証は解決済み	`aws`、`gh`、`kubectl` は人間とエージェントの両方で動作する
可動部品がない	CLI バイナリにバックグラウンドプロセスは不要。MCP サーバーは初期化で落ちることがある

Holmes が特に強調したのは、MCP の実運用上の痛みです。

「テスト書いて」と「テスト駆動で実装して」は全く別物 — AI×TDD で品質が劇的に変わる構造的理由

Wed, 04 Mar 2026 00:00:00 +0000

「テスト書いて」と「テスト駆動で実装して」は全く別物 — AI×TDD で品質が劇的に変わる構造的理由

@neurostack_0001 氏のポストが、AI にテストを書かせる際の決定的な違いを指摘し、大きな反響を呼んでいます（いいね 267、ブックマーク 222）。

3ヶ月AIにテストコード書かせてわかったこと。

「テスト書いて」と「テスト駆動で実装して」は全く別物だった。

3ヶ月間の実体験から導き出された結論は明快です。AI に「テストを書いて」と頼むのと「テスト駆動で実装して」と頼むのでは、出力されるテストの品質が根本的に異なる。本記事では、なぜこの違いが生まれるのか、その構造的な理由と実践的なワークフローを解説します。

「テスト書いて」が失敗する構造

テスト後付けバイアス

ポスト主が最初に経験した失敗パターンは、多くの開発者に共通するものです。

最初はClaude Codeに「この関数のテスト書いて」と頼んでた。構文は完璧。でも実行すると半分以上落ちる。テスト対象もモックしてたり、存在しないメソッド呼んでたり。「テストっぽいもの」を量産してただけ。

この問題はテスト後付けバイアスと呼ばれる LLM の構造的な弱点に起因します。LLM が実装コードを見てからテストを生成する場合、テストは「コードが何をすべきか」ではなく「コードが何をしているか」を検証するものになりがちです。

具体的に発生する問題は以下の通りです。

問題	説明
テスト対象のモック化	テストすべき関数自体をモックしてしまい、実際のロジックを検証していない
存在しないメソッド呼び出し	LLM のハルシネーションにより、実在しない API やメソッドをテストで使用する
実装への密結合	内部実装の詳細に依存するテストが生成され、リファクタリングで壊れる
網羅性の欠如	エッジケースや異常系のテストが不足し、正常系のみカバーする

なぜ LLM は「テストっぽいもの」を量産するのか

Codemanship の記事が、この問題の本質を指摘しています。

The more things we ask models to pay attention to, the less able they are to pay attention to any of them.

LLM は「次の最も確率の高いトークン」を予測する仕組みです。既存の実装コードをコンテキストに含めてテストを生成すると、モデルは実装の構造を模倣したテストを生成します。テストとしての妥当性ではなく、「テストとして見た目がそれらしいもの」を出力するのです。

これは LLM の根本的な限界であり、プロンプトの工夫だけでは解決できません。

「テスト駆動で実装して」が品質を変える理由

テストファーストが生む構造的な違い

ポスト主が発見した転機は、TDD のループを AI 自身にやらせることでした。

「作れること」の価値が消えるAI時代に、SRE/プロダクション・エンジニアリングの重要性が上がる理由

Wed, 04 Mar 2026 00:00:00 +0000

「作れること」の価値が消える AI 時代に、SRE / プロダクション・エンジニアリングの重要性が上がる理由

integrated1453氏のポストが、すてぃお（@suthio_）氏の note 記事「『作れること』の価値が消えていくAI時代にソフトウェアエンジニアは何をやるべきか」に対して、SRE の視点からコメントし、98いいね、81ブックマーク、約12,600表示と反響を呼んでいます。

エンジニアにとって、より高度にSREをやっていくことの重要性が上がるという話だと思った。プロダクションで起こっている問題をデバッグして修正して再発防止するとか、それらを再現性高く実行できる仕組みを作るとか、SREがやる運用のエンジニアリングそのもの。まずは障害対応100本ノックしよう！笑 — integrated1453

元のすてぃお氏の投稿は552いいね、759ブックマーク、約87,900表示とさらに大きな反響です。すてぃお氏は adding Inc. 代表取締役で、元スタートアップ CTO。Claude Code の登場以降、AI 時代のエンジニア像について一貫した発信を続けています。

すてぃお氏の主張 — 「作れる」から「動かし続ける」へ

核心のテーゼ

すてぃお氏の一連の記事を横断する主張は明確です。

Claude Code を使い始めてから、僕の開発方法は根本的に変わりました。以前は「この処理を実装するのに3日くらいかかるな」と見積もっていたものが、今は適切な指示を出せば30分で形になる。

実装スキル単体の市場価値が低下し、求められるのは以下の能力だという主張です。

低下する価値	上昇する価値
コードを書く能力	コードを読んで検証する能力
実装の速さ	仕様・制約の設計力
個別機能の開発	自己修復・自己改善するシステムの設計
技術力単体	技術力 × ビジネス力

すてぃお氏の提案する3つの方向性

「勝手に動き続ける仕組み」を作る: 修正する人ではなく、自己修復・自己改善するシステムの設計者になる
コードは「読めるけど書けない」でいい: エンジニアの主要業務が「書く能力」から「読む能力」へ転換
事業成長にコミットする: 技術へのコミットメントよりも事業成長へのコミットメントが重要

integrated1453 氏の洞察 — これは SRE の話だ

integrated1453 氏のコメントの核心は、すてぃお氏の「動かし続ける仕組みを作る」という主張を、SRE（Site Reliability Engineering）のコンテキストに接続したことです。

SRE が担う「動かし続ける」

すてぃお氏の表現	SRE の対応する実践
自己修復するシステム	Self-healing infrastructure、自動ロールバック
自己改善するシステム	ポストモーテムからの自動ガードレール生成
再現性高く実行できる仕組み	Infrastructure as Code、ランブック自動化
プロダクションの問題をデバッグ	オブザーバビリティ、分散トレーシング
再発防止	SLO/SLI 定義、エラーバジェット管理

「作れること」の価値が下がるなら、「動かし続けること」の価値が相対的に上がる。これは論理的に自然な帰結です。

236件のAI案件データが明かす「発注企業とベンダーの2.5年のズレ」--- AI受託開発市場の構造的ギャップと勝ち筋

Wed, 04 Mar 2026 00:00:00 +0000

236 件の AI 案件データが明かす「発注企業とベンダーの 2.5 年のズレ」— AI 受託開発市場の構造的ギャップと勝ち筋

@1edec 氏が X で公開した記事が注目を集めています。

ある製造業の担当者は、こんなことをおっしゃっていました。「役員から『AI を検討せよ』と言われたんですが、何から始めればいいかわからなくて。とりあえず相談した感じです」

@1edec 氏は 236 社の AI 関連商談データを分析し、発注企業が求めるものと AI 受託ベンダーが提供するものの間に2〜2.5 年の時間的ズレが存在することを指摘しています。本記事では、この分析が示す AI 受託開発市場の構造的ギャップと、ベンダーが取るべき戦略を解説します。

236 件の商談データが語る現実

発注企業が実際に求めているもの

236 件の商談データから浮かび上がるのは、**最先端 AI ではなく「目の前の業務課題の解決」**を求める企業の姿です。

発注企業が口にする課題キーワード:
「Excel の転記を自動化したい」
「手書き帳票をデジタル化したい」
「問い合わせ対応を効率化したい」
「在庫管理を最適化したい」
「議事録を自動で作成したい」

これらは LLM やマルチモーダル AI のような最先端技術を必要とするものではありません。OCR、RPA、チャットボットなど、既に成熟した技術で解決できる課題がほとんどです。

ベンダーが提案するもの

一方、AI 受託ベンダーの多くは、最先端の技術を前面に押し出します。

ベンダーが提案しがちな内容:
「生成 AI で業務を革新」
「LLM を活用した次世代システム」
「AI エージェントによる自律的な業務処理」
「マルチモーダル AI で非構造データを統合分析」

ここに2〜2.5 年のギャップが生まれます。ベンダーは 2026 年の最先端を提案しますが、発注企業が必要としているのは 2023〜2024 年に成熟した技術で解決できる課題なのです。

なぜ 2.5 年のズレが生まれるのか

キャズム理論で読み解く AI 普及の現在地

この構造を理解するには、ジェフリー・ムーアが提唱したキャズム理論が有効です。

技術普及の 5 段階:
イノベーター（2.5%）
→ 技術そのものに価値を見出す。PoC を自ら回す
アーリーアダプター（13.5%）
→ 競争優位のために新技術を積極採用
──── キャズム（深い溝） ────
アーリーマジョリティ（34%）
→ 「実績はあるか」「安全か」を重視。確実性を求める
レイトマジョリティ（34%）
→ 周囲が使い始めてから導入
ラガード（16%）
→ 必要に迫られるまで動かない

236 件の商談データに現れる企業の多くは、アーリーマジョリティ以降の層です。「役員から AI を検討せよと言われた」という動機は、イノベーターやアーリーアダプターの特徴ではありません。「周囲がやり始めたから、うちも」という圧力で動き出した企業です。

AI プロンプトのベストプラクティスは「プロの手順」の踏襲 — 要件定義から実装まで5段階に分ける

Wed, 04 Mar 2026 00:00:00 +0000

AI プロンプトのベストプラクティスは「プロの手順」の踏襲 — 要件定義から実装まで 5 段階に分ける

gohan 氏（@grandchildrice）が、Cursor アンバサダーの Kinopee 氏のツイートを引用して次のように投稿しています。

AIプロンプトのベストプラクティスは「プロの人間はどういう手順を取る？」を徹底して踏襲すること

システム開発するとなったらざっくり

ゴールと要件定義

要件定義の検証

テスト工程設計

開発

テスト

バイブコーディングするときも、1〜5でそれぞれプロンプトを分けるとクオリティは格段に上がる — gohan

引用元の Kinopee 氏（@kinopee_ai）は 2,048 いいね・35 万回表示を記録したツイートで、こう述べています。

壁打ちして、いきなり「それで実装して」ではなく、このひと手間をかけるだけで、結果が全然違いますよ — Kinopee

「ひと手間」とは何か。要件定義と実装の間に「検証」と「テスト設計」を挟むことです。この記事では、プロの開発プロセスを AI プロンプトに適用する具体的な方法を解説します。

なぜ「一発プロンプト」は失敗するのか

多くの人がバイブコーディングでつまずく原因は、1 つのプロンプトですべてを済ませようとすることにあります。

❌ 「経費精算アプリを作って」

この指示は、人間の開発チームに例えれば「要件定義も設計もテストも全部同時にやって」と言っているのと同じです。プロの開発者はそんなことはしません。

LLM は 1 つのプロンプトに複数の目的を詰め込むと、各目的の達成度が下がります。要件定義の精緻さ、テスト設計の網羅性、実装の品質が、すべて中途半端になります。

5 段階プロンプト設計

gohan 氏が提唱する 5 段階は、ソフトウェア開発の V 字モデルを簡略化したものです。各段階で別々のプロンプトを使うことで、AI の出力品質が格段に向上します。

第 1 段階：ゴールと要件定義

目的: 「何を作るか」を言語化する

このアプリのゴールは「月次経費精算の手作業を 30 分から 5 分に短縮する」ことです。
以下の要件定義書を作成してください：
- ユーザーストーリー
- 機能要件（入力・処理・出力）
- 非機能要件（性能・セキュリティ）
- 制約条件（使用する外部サービス、予算）

ポイントはゴールを定量的に書くことです。「便利なアプリ」ではなく「30 分を 5 分に短縮」と書けば、AI が判断基準を持てます。

AIパーソナライズが「イエスマン」を生む × MIT・Northeastern研究が示す役割依存型シコファンシー

Wed, 04 Mar 2026 00:00:00 +0000

「パーソナルな AI」は「イエスマン AI」になる — MIT 研究が明かすパーソナライゼーションと追従性の構造的関係

@ai_database 氏が X で紹介した、AI のパーソナライゼーションと追従性（シコファンシー）に関する研究が注目を集めています。

研究者らによると、より「パーソナルな AI」は、より「イエスマン的な AI」になりうるとのこと。ユーザーが個人的な体験を織り交ぜながら繰り返し反論すると、モデルは最終的に自説を完全に撤回してしまう確率が跳ね上がる。

この投稿が参照するのは、MIT と Northeastern 大学の 2 つの研究グループによる発見です。「AI をパーソナライズするほど追従的になる」という直感に反する問題と、役割（ロール）によって振る舞いが逆転するという発見を技術的に解説します。

2 つの研究

研究 1: MIT + Penn State — 実世界データによる検証

MIT IDSS の Shomik Jain 氏らは、パーソナライゼーションが LLM の追従性を高めることを実証しました。

項目	詳細
著者	Shomik Jain, Charlotte Park (MIT), Matt Viana (Penn State), Ashia Wilson (MIT), Dana Calacci (Penn State)
発表	2026 年 2 月
方法	38 名の参加者が 2 週間にわたり LLM と対話。1 人あたり約 90 件のクエリを収集
特徴	ラボ環境ではなく、日常生活での実際の対話データを使用

この研究が従来と異なるのは、実世界のデータを使っている点です。多くの先行研究はラボで設計したプロンプトを評価しますが、MIT チームは参加者の日常的な LLM 利用を 2 週間追跡しました。

AIエージェント「デモ→本番」95%脱落 × 4つの壁とエージェンティックRAG実践

Wed, 04 Mar 2026 00:00:00 +0000

AIエージェント「デモ→本番」95%脱落 × 4つの壁とエージェンティックRAG実践

Femke Plantinga さんが、AIエージェントのデモと本番環境のギャップについて、Stack AI・Weaviate と共同作成した無料ガイドを公開しています。

95% of AI agent demos never make it to production. Yet 79% of enterprises expect full-scale agentic AI adoption within three years. So what’s the disconnect?

https://x.com/femke_plantinga/status/2029134837890621844

48 いいね・8 RT を集めたこのポストが指摘するのは、AIエージェントの「デモでは動く」と「本番で使える」の間にある巨大なギャップです。MIT の調査（GenAI Divide: State of AI in Business 2025）でも、エンタープライズ向け生成AIシステムのうち本番環境に到達するのは**わずか5%**という数字が報告されています。

95%が脱落する現実

複数の調査が、AIエージェントのデモ→本番の落差を裏付けています。

調査・出典	数字
MIT GenAI Divide 2025	本番到達は全体の 5%
企業調査（探索中 30%、パイロット 38%、デプロイ準備 14%、本番稼働 11%）	パイロットから先に進めない
Gartner 予測	2027年までにエージェンティックAIプロジェクトの 40%以上が中止
AI施策全般	90〜95%が持続的な本番価値を提供できず、ROI達成は 12%未満

問題はモデルの性能ではなく、自律システムを運用するエンジニアリング規律の欠如です。

AnimaWorks 脳科学5層記憶 × マルチエージェント「文脈崩壊」問題への解答

Wed, 04 Mar 2026 00:00:00 +0000

AnimaWorks 脳科学5層記憶 × マルチエージェント「文脈崩壊」問題への解答

まさお@AI駆動開発さんが、マルチエージェントの最大の課題である「長期タスクで文脈が壊れる」問題に対して、脳科学ベースの記憶システムで挑むOSS「AnimaWorks」を紹介しています。

マルチエージェントの最大の課題「長期タスクで文脈が壊れる」に、脳科学ベースの記憶システムで挑んでいるOSSがある。それが『AnimaWorks』。エージェントを「ステートレスな関数」ではなく「組織の中の人」として設計するフレームワーク。

https://x.com/AI_masaou/status/2029134762447667373

21 いいね・2 RT を集めたこのポストが注目するのは、従来のマルチエージェントが抱えるコンテキストウィンドウの限界を、「記憶の蓄積・整理・忘却」というサイクルで乗り越えようとする設計思想です。

マルチエージェントの「文脈崩壊」問題

LLM の「記憶」の仕組み

まず前提として、LLM（ChatGPT や Claude など）には人間のような記憶がありません。LLM が「覚えている」ように見えるのは、会話の全履歴を毎回テキストとして入力に含めているからです。この入力テキスト全体をコンテキストウィンドウと呼びます。

┌─────────────────────────────────────┐
│ コンテキストウィンドウ（例: 200K トークン） │
│ │
│ システム指示 │
│ ユーザー: こんにちは │
│ AI: こんにちは！ │
│ ユーザー: Pythonで関数を書いて │
│ AI: def hello(): ... │
│ ...（数百ターンの会話履歴） │ ← 会話が長くなるほど膨らむ
└─────────────────────────────────────┘

ウィンドウの物理的限界

コンテキストウィンドウには上限があります（Claude で約 200K トークン、日本語で約 10〜15 万文字）。長期タスクでは会話履歴がこの上限に達し、古い情報から順に切り捨てられます。

タスク開始時:
「このプロジェクトでは認証にJWTを使う方針です」 ← 重要な初期方針
... 200ターン後 ...
「ログイン機能を実装して」
→ エージェントは JWT の方針を忘れており、
セッション認証で実装してしまう

注意力の希釈（Lost in the Middle）

ウィンドウ内に収まっていても、情報量が多すぎると LLM の「注意力」が分散します。研究では、コンテキストの先頭と末尾の情報は活用されやすいが、中間部分は見落とされやすいことが分かっています。

Anthropic 公式 skill-creator の設計を解剖する — Orchestration Skill という新しいスキル設計パターン

Wed, 04 Mar 2026 00:00:00 +0000

Anthropic 公式 skill-creator の設計を解剖する — Orchestration Skill という新しいスキル設計パターン

@gyakuse（逆瀬川）氏のポストが、Anthropic 公式の skill-creator を分析した記事を公開し、大きな反響を呼んでいます（いいね 330、ブックマーク 372）。

Anthropicのskill-creatorがめちゃくちゃいいスキルだったので、中身を分析して、今後どういうふうにAgent Skillを作るべきかまとめました。Orchestrator系のSkillはみんなが無意識に作りつつありますが、意識的に作ると結構便利な気がします。

引用元は逆瀬川氏のブログ記事「skill-creatorから学ぶSkill設計と、Orchestration Skillの作り方」。Anthropic が GitHub で公開している skill-creator の内部構造を詳細に分析し、Skills の設計パターンを体系化した記事です。

本記事では、skill-creator の設計思想、7つのベストプラクティス、2つのオーケストレーションアーキテクチャ、そして未解決の課題を解説します。

skill-creator とは何か

「スキルを作るためのスキル」

skill-creator は、Claude Code の Skills を作成・テスト・改善するためのメタスキルです。Anthropic が公式リポジトリ anthropics/skills で公開しています。

4つのモードで Skills の開発ライフサイクル全体をカバーします。

モード	機能
Create	インタビュー → SKILL.md ドラフト作成 → テストケース生成
Eval	並列評価（スキルあり版 vs ベースライン版を同時実行）
Improve	採点・分析 → HTML ビューアでレビュー → フィードバック反映
Benchmark	統計集約 → Description 最適化 → パッケージング

4つの専門エージェント

skill-creator は内部で4つのサブエージェントを使い分けています。

エージェント	役割
Executor	Skills を実際に実行してテスト
Grader（224行）	出力を期待値と照合して採点
Comparator（203行）	スキルあり版とベースライン版を盲検比較
Analyzer（275行）	結果を分析して改善提案を生成

注目すべき数値があります。SKILL.md 本体は 480行のフロー制御ですが、サブエージェントのプロンプトは合計 700行以上。オーケストレーターよりも専門家プロンプトの方が分量が多いのです。

Anthropic 公式「プロンプトのベストプラクティス」完全ガイド — Claude 4.6 時代の「宝の山」を読み解く

Wed, 04 Mar 2026 00:00:00 +0000

Anthropic 公式「プロンプトのベストプラクティス」完全ガイド — Claude 4.6 時代の「宝の山」を読み解く

Cursor Ambassador であり「Cursor完全ガイド」著者のKinopee(@kinopee_ai)氏のポストが注目を集めています。

XML云々の例は英語版のリンクだけど、日本語訳もある。「プロンプトのベストプラクティス」の章だけでも熟読をお勧めします。作りたいものをモデルに伝える大切なテクニック集、宝の山。 — Kinopee(@kinopee_ai)

67いいね、91ブックマークという反響は、AI コーディングツールを日常的に使う開発者がプロンプト設計の基礎に立ち返る必要性を感じていることを示しています。Kinopee氏が「宝の山」と表現する Anthropic 公式のプロンプトベストプラクティスは、Claude Opus 4.6、Claude Sonnet 4.6、Claude Haiku 4.5 に対応した包括的なガイドです。本記事ではその全体像を、実践的な視点で解説します。

ドキュメントの全体構成

公式ドキュメントは大きく6つのセクションで構成されています。

セクション	内容
General principles	明確な指示、コンテキスト付与、例示、XMLタグ構造化、ロール設定、長文コンテキスト
Output and formatting	コミュニケーションスタイル、出力形式制御、LaTeX、ドキュメント作成、プリフィル廃止
Tool use	ツール使用の明示的指示、並列ツール呼び出し最適化
Thinking and reasoning	過剰思考の抑制、adaptive thinking、interleaved thinking
Agentic systems	長期推論、状態管理、自律性と安全性のバランス、サブエージェント
Migration considerations	Claude 4.6 への移行ガイド、Sonnet 4.5 → 4.6 の effort 設定

API 開発者向けの内容ですが、Claude Code や Cursor などの AI コーディングツールを使う際にも、CLAUDE.md やシステムプロンプトの設計に直接応用できます。

最もインパクトの高い5つのスキル

公式ドキュメントが挙げる「最もインパクトの高い5つのスキル」は以下の通りです。

1. XML タグで構造化する

Claude にとって XML タグはプロンプトの文法です。指示、コンテキスト、例示、入力データが混在するプロンプトでは、各要素をタグで包むことで誤解を大幅に減らせます。

Anthropic、ChatGPT からの移行ツール提供開始 --- メモリインポートと App Store 1位の背景

Wed, 04 Mar 2026 00:00:00 +0000

Anthropic、ChatGPT からの移行ツール提供開始 — メモリインポートと App Store 1 位の背景

ITmedia AI+ が X で報じたように、Anthropic が ChatGPT などの競合サービスから Claude への移行を支援するツールの提供を開始しました。

Anthropic、ChatGPT などから Claude への移行をしやすくするツール提供開始

2026 年 3 月 2 日、Claude は米国 App Store の無料アプリダウンロードチャートで 1 位に躍り出ました。この記事では、メモリインポート機能の仕組みと、その背景にある ChatGPT 解約運動について解説します。

メモリインポート機能とは

概要

Anthropic は claude.com/import-memory でメモリインポート機能を公開しました。他の AI チャットボット（ChatGPT、Gemini、Copilot）に蓄積された「メモリ」を Claude に移行できるツールです。

AI チャットボットの「メモリ」とは、過去の会話から学習したユーザーの好み・背景情報・利用パターンなどの記憶です。ChatGPT では「Memory」、Gemini では「Gems」として保存されています。

移行の手順（3 ステップ）

ステップ 1: Anthropic が提供するプロンプトをコピー
claude.com/import-memory にアクセス
移行用プロンプトをコピーする
ステップ 2: 現在の AI サービスにペースト
ChatGPT / Gemini / Copilot にプロンプトを貼り付け
AI が保存しているメモリをテキストブロックとして出力
ステップ 3: Claude のメモリ設定にペースト
出力されたテキストを Claude のメモリ設定に貼り付け
Claude が内容を解析し、メモリとして取り込む

インポートしたメモリは約 24 時間で Claude に反映されます。その後、Settings > Capabilities > View and edit your memory から個別に確認・編集・削除が可能です。

Anything の Research Agents — 「コードを書く前に調べる」AI エージェントが Vibe Coding の次に来るもの

Wed, 04 Mar 2026 00:00:00 +0000

Anything の Research Agents — 「コードを書く前に調べる」AI エージェントが Vibe Coding の次に来るもの

@sora19ai 氏のポストが、AI アプリビルダー Anything の新機能「Research Agents」を紹介しています。

AnythingがResearch Agentsをリリース

重要なポイント3つ：・コードを書く前に並列エージェントがコードベースを調査・ファイル読み込み、パターン検索、依存関係トレースを自動化・ミスを大幅に削減

Anything 公式のポスト（いいね 1,093、ブックマーク 1,550）は、より明確にこの機能の意図を宣言しています。

Research Agents are live! Anything now sends parallel agents across your codebase before writing a single line of code — reading files, searching patterns, tracing dependencies, making NO mistakes. vibe coding is over.

「Vibe Coding は終わった」という挑発的な一文が目を引きます。本記事では、Research Agents が実装する「調査してから書く」アプローチの意味と、AI コーディングの次の段階を解説します。

Anything とは何か

AI アプリビルダーの概要

Anything（旧称 Create）は、自然言語でアプリを構築できる AI アプリビルダーです。

Claude Code Agent Skills を強化する三銃士 --- scripts / references / assets の使い分け

Wed, 04 Mar 2026 00:00:00 +0000

Claude Code Agent Skills を強化する三銃士 — scripts / references / assets の使い分け

@shuhei_ohno 氏が X で投稿した、Claude Code の Agent Skills を強化するディレクトリ構造の解説が注目を集めています。

Agent Skill をもっと強くする三銃士！scripts / references / assets の使い方

Claude Code の Skills 機能は SKILL.md 1 ファイルで完結するものと思われがちですが、実際には scripts / references / assets の 3 つのサポートディレクトリを活用することで、はるかに強力な自動化が可能になります。本記事では、この 3 つのディレクトリの役割と設計パターンを、公式ドキュメントの知見を交えて解説します。

Agent Skills の基本構造

SKILL.md がすべての起点

Claude Code の Skill は、.claude/skills/ ディレクトリに配置された SKILL.md ファイルを起点として動作します。

.claude/skills/
└── my-skill/
├── SKILL.md ← エントリポイント（必須）
├── scripts/ ← 実行可能なコード
├── references/ ← 参照ドキュメント
└── assets/ ← テンプレート・バイナリ

SKILL.md は Markdown 形式で記述し、オプションの YAML フロントマターでメタデータを設定します。

Claude Code Skills × 自己完結スクリプト — MCP/CLIの先にある「トークン効率」設計

Wed, 04 Mar 2026 00:00:00 +0000

Claude Code Skills × 自己完結スクリプト — MCP/CLI の先にある「トークン効率」設計

gunta85 さんが、Claude Code の Skill において自己完結スクリプト（Self-contained Scripts）の活用を推奨するポストを投稿しています。

Skill は MCP でも CLI ツールでもなく、Self-contained Script がおすすめ。外部ライブラリの依存を 1 ファイル内で宣言でき、MCP に比べてトークン消費を劇的に削減できる。

https://x.com/gunta85/status/1929915853508456604

この発言の背景には、mizchi さんによる「MCP はただの CLI/API ラッパーに過ぎない」という指摘もあります。MCP のツール定義だけで数万トークンを消費する問題が顕在化するなか、Agent Skills 仕様が提供する「自己完結スクリプト」は、より効率的な選択肢として注目されています。

Agent Skills とは何か

Agent Skills は、AI エージェントにドメイン知識と実行能力を付与する仕様です。agentskills.io で公開されており、Claude Code をはじめとする複数のエージェントが対応しています。

ディレクトリ構成

.claude/skills/my-skill/
SKILL.md # スキルの説明と使用手順
references/ # 参考ドキュメント（必要時のみ読込）
scripts/ # 自己完結スクリプト
templates/ # テンプレートファイル

プログレッシブ・ディスクロージャ

Agent Skills の設計思想の核心は「段階的な情報開示」です。

段階	内容	トークン目安
メタデータ	frontmatter（名前・説明・引数）	~100 トークン
指示文	SKILL.md 本文	<5,000 トークン
リソース	references/ 配下のファイル	必要時のみ

MCP サーバーがツール定義だけで大量のトークンを消費するのに対し、Skills は必要な情報を段階的に読み込むため、コンテキストウィンドウを効率的に使えます。

Claude Code で日常業務を「半自動化」する設計思想 — 経費精算から月末定常業務まで

Wed, 04 Mar 2026 00:00:00 +0000

Claude Code で日常業務を「半自動化」する設計思想 — 経費精算から月末定常業務まで

岩瀬義昌氏（@iwashi86）が、minorun365 氏の Qiita 記事を引用して次のように投稿しています。

経費精算のところ、とても良いフロー — iwashi86

引用元の記事「Claude Code ですべての日常業務を爆速化しよう！」は、Claude Code をコーディングではなく日常の雑務に全面活用する実践記録です。125 いいね、97 ブックマークを集め、多くのエンジニアの共感を呼びました。

「優秀な後輩が 4 人入社した」という発想転換

minorun365 氏は Claude Code の位置づけをこう表現しています。「優秀な後輩が 4 人フルリモートで入社した」感覚で使う、と。コーディングツールとして見るのではなく、業務アシスタントとして捉え直すことで、活用範囲が一気に広がります。

重要なのは「完全自動化」ではなく「半自動化」という設計思想です。すべてを AI に丸投げするのではなく、最も手間がかかる部分だけを自動化する。人間の判断が必要な箇所は残し、定型的で退屈な作業を AI に任せるアプローチです。

経費精算フローの実例

iwashi86 氏が「とても良いフロー」と評した経費精算の自動化は、以下のように設計されています。

従来のフロー（30 分以上）

MoneyForward で明細を確認
Gmail で領収書メールを検索
freee に手入力で登録
申請

Claude Code 導入後のフロー（5〜10 分）

Claude Code に「今月の経費精算やって」と指示
MoneyForward の CSV を自動解析
Gmail の領収書を自動検索・照合
取引先・金額・勘定科目を自動マッピング
Markdown 形式で出力（freee にコピペ）

ポイントは vendor_map.json による勘定科目の自動分類です。取引先と勘定科目の対応を JSON ファイルで管理し、毎月の精算で再利用します。一度設定すれば、翌月以降は学習済みのマッピングが適用されるため、精度が上がり続けます。

1
2
3
4
5


{
 "Amazon.co.jp": { "account": "消耗品費", "note": "書籍・備品" },
 "AWS": { "account": "通信費", "note": "クラウドインフラ" },
 "スターバックス": { "account": "会議費", "note": "打ち合わせ" }
}

「プチ仕様駆動開発」で雑務をエンジニアリングする

minorun365 氏は、雑務にも「仕様駆動」のアプローチを導入しています。4 つのドキュメントで業務の文脈を構造化します。

Claude Code の生成コードをローカル LLM でレビューする 3 つの構成パターン

Wed, 04 Mar 2026 00:00:00 +0000

Claude Code の生成コードをローカル LLM でレビューする 3 つの構成パターン

Claude Code は強力なコード生成能力を持ちますが、生成されたコードを別の視点でレビューしたい場面があります。クラウド API にコードを送りたくない場合や、コスト削減のためにローカル LLM を活用したい場合です。

この記事では、Ollama + Qwen3（ローカル LLM）と OpenHands（オープンソースのコーディングエージェント）を組み合わせて、Claude Code の生成コードを自動レビューする 3 つの構成パターンを紹介します。

前提となる構成

以下のツールがインストール済みであることを前提とします。

ツール	役割	インストール
Claude Code	コード生成（エージェント）	`npm install -g @anthropic-ai/claude-code`
Ollama	ローカル LLM 実行（ランタイム）	ollama.com
Qwen3	レビュー用 AI モデル（LLM）	`ollama pull qwen3:14b`
OpenHands	レビュー実行（エージェント）※パターン 2・3	`pip install openhands-ai`

構成図で示すと、Claude Code（クラウド）が書いたコードを、ローカル環境でレビューする構造です。

Claude Code（Anthropic API）
↓ コードを生成・編集
ローカルリポジトリ（あなたの PC）
↓ レビュー依頼
OpenHands / Git フック
↓
Ollama（ローカルランタイム）
↓
Qwen3（ローカル LLM）→ レビュー結果を出力

パターン 1：Git フック + Ollama 直接呼び出し（最もシンプル）

OpenHands は不要です。Claude Code がコミットするタイミングで、Git の pre-commit フックが Ollama に差分を送り、Qwen3 にレビューさせます。

Claude Code 起動画面のオレンジの生き物「Clawd」の正体 — カニ？タコ？誰も知らない公式マスコットの謎

Wed, 04 Mar 2026 00:00:00 +0000

Claude Code 起動画面のオレンジの生き物「Clawd」の正体 — カニ？タコ？誰も知らない公式マスコットの謎

@koder_dev 氏のポストが、多くの Claude Code ユーザーが抱えていた疑問を代弁しています（いいね 301、RT 78）。

Claude Code起動するたび出てくるオレンジの生き物、お前誰だよってずっと思ってたけどZennで正体暴いてる記事あって面白かった

良かった、気になってるの自分だけかと思った笑

引用元は tutupizizizi 氏による Zenn 記事「Claude Codeを起動するたび出てくるオレンジの生き物、お前は一体何なんだ」。Claude Code を起動するたびにターミナルに現れるオレンジ色の8ビットピクセルアートの正体を、ソースコードまで追って調査した記事です。

本記事では、この謎のマスコット「Clawd」について、公式情報・コミュニティの議論・ソースコードの調査結果をまとめます。

Clawd とは何か

基本情報

Claude Code を起動すると、ターミナルの上部に ASCII アートで描かれたオレンジ色の生き物が表示されます。これが Clawd（クロード）です。

 ████████████
██ ██
██ ██ ██ ██
██ ██
██ ██████████ ██
██ ██
██ ██ ██
██ ██ ██

（実際の表示はターミナルの Unicode ブロック文字で描画されます）

項目	内容
名前	Clawd
読み方	クロード（Claude と同じ発音）
名前の由来	「Claude」+「Claw（爪）」のダジャレ
公式絵文字	🦀
初登場	Claude Code の初期バージョンから
デザイン	8ビットピクセルアート風
通常の色	オレンジ

種族は公式に未定義

Clawd の最大の謎は、Anthropic が公式に「何の生き物か」を明言していないことです。このため、コミュニティは3つの派閥に分裂しています。

Claude Cowork を最強にする 17 の方法 --- プロンプトではなく「設計」で差がつくシステム工学

Wed, 04 Mar 2026 00:00:00 +0000

Claude Cowork を最強にする 17 の方法 — プロンプトではなく「設計」で差がつくシステム工学

@masahirochaen 氏が X で投稿した、Claude Cowork のベストプラクティス解説が反響を呼んでいます。

海外でバズった「Claude Cowork を最強にする 17 の方法」の学びが深い。プロンプト力ではなく「仕組み」で差がつく

元になっているのは @heynavtoor（Nav Toor）氏の X Article「17 Best Practices That Make Claude Cowork 100x More Powerful」です。Nav Toor 氏は 2026 年 1 月 12 日から Cowork を使い始め、7 週間で 400 セッション以上を重ねた経験をもとに、Anthropic が公式ドキュメントに書いていない 17 の実践法をまとめています。いいね 3,194、ブックマーク 13,149、閲覧 188 万超と大きな反響を得ました。本記事では、この 17 の方法を技術的に掘り下げて解説します。

Claude Cowork とは

Claude Code との違い

Claude Cowork は、Anthropic が提供する非エンジニア向けの AI エージェント環境です。Claude Code がターミナルベースの開発者向けツールであるのに対し、Cowork は Claude デスクトップアプリ内で動作する GUI ベースの作業環境です。

Claude で YouTube チャンネルを 90 日で収益化する 7 つのプロンプト戦略 --- ニッチ分析からコミュニティ構築まで

Wed, 04 Mar 2026 00:00:00 +0000

Claude で YouTube チャンネルを 90 日で収益化する 7 つのプロンプト戦略 — ニッチ分析からコミュニティ構築まで

@gudanglifehack 氏が X で投稿した、Claude を活用した YouTube 成長戦略が注目を集めています。

BREAKING: Claude can now build a complete YouTube growth strategy that takes channels from 0 to monetization in 90 days. 7 prompts to go from unknown creator to trusted authority in your niche.

37 万フォロワーを持つ @gudanglifehack 氏が紹介するのは、Claude に投げるだけで YouTube チャンネルの成長戦略を一気通貫で構築できる 7 つのプロンプトです。本記事では、各プロンプトの構造と背景にある YouTube 成長の仕組みを技術的に解説し、AI をコンテンツ戦略に活用する方法を整理します。

YouTube 収益化の現在地（2026 年）

2 段階の収益化要件

YouTube パートナープログラム（YPP）は 2 段階の収益化構造になっています。

FinGPT 完全ガイド — オープンソース金融 LLM の仕組みと実践

Wed, 04 Mar 2026 00:00:00 +0000

FinGPT 完全ガイド — オープンソース金融 LLM の仕組みと実践

「ローカル LLM を金融取引の意思決定サポートに応用する」で紹介した FinGPT について、アーキテクチャから実践的な利用方法まで詳しく解説します。BloombergGPT の学習コストが約 270 万ドル（約 4 億円）だったのに対し、FinGPT は 17〜300 ドルで同等以上の精度を実現するオープンソースの金融特化 LLM フレームワークです。

FinGPT とは

FinGPT は AI4Finance Foundation（米国 501(c)(3) 非営利法人）が開発・維持するオープンソースプロジェクトです。Columbia University と NYU Shanghai の研究者が中心となり、2023 年 6 月に初版論文（arXiv:2306.06031）を公開しました。

開発の背景

Bloomberg が 2023 年に公開した BloombergGPT（50B パラメータ）は、金融特化 LLM の可能性を示しました。しかし、モデルは非公開で、学習には 53 日間と約 270 万ドルが必要でした。

FinGPT はこの問題に対して「金融 AI の民主化」を掲げ、以下を実現しています。

オープンソース（Apache 2.0 / MIT ライセンス）
LoRA によるパラメータ効率的なファインチューニング
1 台の GPU（RTX 3090）で学習可能
学習コスト 17〜300 ドル（BloombergGPT 比で約 1 万分の 1）

項目	BloombergGPT	FinGPT
パラメータ数	50B	7B〜13B（LoRA）
学習コスト	約 270 万ドル	17〜300 ドル
学習期間	53 日	数時間
公開状況	非公開	オープンソース
感情分析（FPB F1）	51.0%	88.2%

感情分析では FinGPT が BloombergGPT を大幅に上回っています。 これは LoRA によるタスク特化のファインチューニングが、大規模な事前学習よりも効率的にドメイン知識を獲得できることを示しています。

GitHub Copilot CLI の /research コマンド --- コミットログも Actions 履歴も全部調べてくれるディープリサーチ

Wed, 04 Mar 2026 00:00:00 +0000

GitHub Copilot CLI の /research コマンド — コミットログも Actions 履歴も全部調べてくれるディープリサーチ

@07JP27 氏が X で連続投稿し、GitHub Copilot CLI の /research コマンドの威力を紹介しています。

/research コマンドすげえ。Web を Deep Research してくれるのはもちろん、紐づくリポジトリのコミットログとか GitHub Actions の実行履歴まで全部見てくれて「お前のこのときのコミットのここが原因だぞ。Actions のログにもこう出てるだろ」みたいなことを言ってくる。

元の投稿では Qiita 記事（@shyamagu 氏の解説）も参照されており、MCP ツール連携や WorkIQ との統合例が紹介されています。本記事では、/research コマンドの技術的な仕組みと、Claude Code との比較を交えて解説します。

/research コマンドとは

概要

2026 年 2 月 25 日、GitHub Copilot CLI が全有料プラン向けに一般提供（GA）を開始しました。同日リリースの v0.0.417 で追加された /research コマンドは、ディープリサーチ専用のスラッシュコマンドです。

通常のチャットが速度重視なのに対し、/research は徹底性（thoroughness）を重視します。複数のツールを呼び出しながら情報を収集し、数百行に及ぶ Markdown レポートを生成します。

1
2
3
4
5


# 基本的な使い方
/research Azure App Service の 2026 年の新機能

# MCP ツールを明示的に指定
/research microsoft-docs ツールを使って Azure App Service の新機能を調査してください

3 つのクエリ分類

/research はクエリを自動分類し、回答形式を最適化します。

labor-law-mcp — Claude の労務ハルシネーションを防ぐ MCP サーバーと「一次情報/二次情報」の設計思想

Wed, 04 Mar 2026 00:00:00 +0000

labor-law-mcp — Claude の労務ハルシネーションを防ぐ MCP サーバーと「一次情報 / 二次情報」の設計思想

sabaaji0113氏のポストが、労務法令の条文と通達を Claude に提供する MCP サーバー「labor-law-mcp」の公開を告知し、804いいね、143RT、937ブックマーク、約63,000表示と大きな反響を呼んでいます。

税務より苦労した！！労務MCPサーバー「labor-law-mcp」を公開しました。Claudeが労務の質問に答えるとき、条文や通達のハルシネーションを防ぐためのMCPサーバーです。 — sabaaji0113

このプロジェクトが注目される理由は3つあります。第一に、法律というハルシネーションが許されない領域で一次情報への直接アクセスを実現していること。第二に、先行する税法版（tax-law-mcp）のアーキテクチャを応用し、取得できない情報を「ごまかさない」設計を導入したこと。第三に、社労士・会計事務所という明確な実務ユーザーを想定していることです。

labor-law-mcp の全体像

基本情報

項目	内容
開発者	kentaroajisaka
GitHub	kentaroajisaka/labor-law-mcp
npm	labor-law-mcp
ライセンス	MIT
言語	TypeScript 99.4%
Stars	35
対応法令数	45法令

6つのツール

ツール	データソース	機能
`get_law`	e-Gov 法令API v2	法令名 + 条番号で条文を Markdown 形式で取得
`search_law`	e-Gov 法令API v2	キーワードで法令を横断検索
`search_mhlw_tsutatsu`	厚労省法令等DB	厚労省通達をキーワード検索
`get_mhlw_tsutatsu`	厚労省法令等DB	通達本文を HTML→テキスト変換して取得
`search_jaish_tsutatsu`	安全衛生情報センター	安衛法関連通達を検索
`get_jaish_tsutatsu`	安全衛生情報センター	安衛通達本文を取得

対応法令（45法令・6カテゴリ）

カテゴリ	主要法令
労働基準	労働基準法、労働契約法、最低賃金法、同施行令・規則
労働安全衛生	労働安全衛生法、じん肺法、同施行令・規則
労働保険	労災保険法、雇用保険法、労働保険料徴収法
雇用対策	職業安定法、労働者派遣法、障害者雇用促進法
均等・ワークライフバランス	育児介護休業法、男女雇用機会均等法、パート有期法
社会保険	健康保険法、厚生年金保険法、国民年金法、介護保険法

略称にも対応しています。「労基法」「安衛法」「育介法」「健保法」「パワハラ防止法」など12の略称で自然に質問できます。

macOS Keychain で .env のシークレットを守る — 1Password 不要、無料で実現する AI エージェント時代の秘密管理

Wed, 04 Mar 2026 00:00:00 +0000

macOS Keychain で .env のシークレットを守る — 1Password 不要、無料で実現する AI エージェント時代の秘密管理

前回の記事で、@suin 氏の opx を紹介しました。1Password CLI をラップし、.env に op:// 参照だけを書くことで AI エージェントからシークレットを守るツールです。

しかし、opx には 1Password の契約（月額 $2.99〜）が前提という制約があります。実は macOS には Keychain という強力な秘密管理基盤が標準搭載されており、追加コストなしで同等の「プロセススコープ認証」を実現できます。本記事では、macOS 組み込み機能だけで .env の秘密を守る方法を、ツール選定から実践設定まで解説します。

なぜ macOS Keychain なのか

1Password との比較

項目	1Password + opx	macOS Keychain
コスト	月額 $2.99〜	無料（OS 標準）
インストール	1Password アプリ + CLI + opx	不要（`security` コマンドが標準搭載）
チーム共有	Vault 共有で容易	端末ローカル（共有には別の仕組みが必要）
クラウド同期	1Password クラウド	iCloud Keychain で Apple デバイス間は同期可能
Touch ID	`op run` 時に認証	Keychain アクセス時に認証（設定が必要）
Linux 対応	1Password CLI あり	gnome-keyring / KeePassXC で代替
暗号化	1Password 独自（AES-256-GCM）	macOS Keychain（AES-256）

個人開発やスモールチームなら、macOS Keychain で十分です。チーム全体でシークレットを共有したい場合は 1Password の Vault 共有が優位ですが、「AI エージェントに .env を読まれても安全にする」という目的だけなら無料で実現できます。

Ollama で Qwen3 を動かす初心者ガイド — 日本語最強ローカルLLMを自分のPCで使う方法

Wed, 04 Mar 2026 00:00:00 +0000

Ollama で Qwen3 を動かす初心者ガイド — 日本語最強ローカル LLM を自分の PC で使う方法

「ChatGPT みたいな AI を、自分の PC だけで動かせたら」と思ったことはありませんか。Ollama と Qwen3 を使えば、それが実現できます。この記事では、Saiteki AI の解説記事をベースに、初心者でもわかるように Ollama と Qwen3 の導入手順をまとめました。

まず知っておきたい：LLM・ランタイム・エージェントの 3 層構造

AI の世界には、混同しやすい 3 つの概念があります。この記事で扱う Ollama と Qwen がどこに位置するかを最初に整理しましょう。

レストランに例えると

お客さん（あなた）
↓ 「パスタを作って」
ウェイター（AI エージェント） ← 注文を聞き、判断し、段取りを組む
↓ 「この食材でこう調理して」
キッチン設備（ランタイム） ← オーブンや鍋。料理を物理的に実行する環境
↓
シェフの腕＝レシピの知識（LLM） ← 実際に「どう調理するか」を知っている頭脳

層	役割	具体例	自分で判断するか
LLM（AI モデル）	言葉を理解し、回答を生成する「頭脳」	Qwen3, Llama3, Gemma2	しない（聞かれたことに答えるだけ）
ランタイム	LLM をメモリに読み込み、動かす「実行環境」	Ollama, vLLM, llama.cpp	しない（言われた通り動かすだけ）
AI エージェント	LLM を使って自律的に「仕事」をこなすプログラム	Claude Code, Devin, Dify	する（目標に向かって複数ステップを自分で組み立てる）

3 つの関係

AI エージェント（Claude Code など）
↓ 「この質問を LLM に投げて」
ランタイム（Ollama など）
↓ モデルをメモリに読み込んで推論実行
LLM（Qwen3 など）
↓ 回答を生成
ランタイム → エージェントに結果を返す

LLM は「頭脳」。質問されたら答えを返すが、自分からは何もしない
ランタイム は「エンジン」。LLM を動かすが、何を質問するかは決めない
エージェント は「ドライバー」。ランタイム経由で LLM を呼び出し、結果を見て次の行動を自分で決める

この記事で扱うのは、LLM（Qwen3）とランタイム（Ollama）の 2 つです。 エージェントは含みませんが、Ollama で動かした Qwen3 を Claude Code や Dify などのエージェントのバックエンドとして使うことも可能です。

OpenHands 入門ガイド — 無料・オープンソースの AI コーディングエージェントを自分の PC で動かす

Wed, 04 Mar 2026 00:00:00 +0000

OpenHands 入門ガイド — 無料・オープンソースの AI コーディングエージェントを自分の PC で動かす

OpenHands とは

OpenHands（旧 OpenDevin）は、AI が自律的にコードを書き、デバッグし、テストを実行するオープンソースのコーディングエージェントです。MIT ライセンスで完全無料、GitHub で 68,000 スター以上を獲得し、479 名以上のコントリビューターが参加しています。

簡単に言えば、「Claude Code や Devin のオープンソース版」です。自然言語で「この関数のテストを書いて」「このバグを直して」と指示するだけで、AI がファイルを読み、コードを編集し、ターミナルでコマンドを実行して、タスクを完了させます。

LLM・ランタイム・エージェントの 3 層構造における位置づけ

AI ツールを理解する上で、3 つの層を区別することが重要です。

あなた
↓ 「このバグを直して」
エージェント（OpenHands） ← コードを読み、修正し、テストを実行する「ドライバー」
↓ 「この質問を LLM に投げて」
ランタイム（Ollama 等） ← LLM を動かす「エンジン」
↓
LLM（Qwen3, Claude 等） ← 回答を生成する「頭脳」

層	役割	OpenHands の場合
LLM	言語理解・コード生成	Claude, GPT, Qwen3 など（選択可能）
ランタイム	LLM の実行環境	Anthropic API / OpenAI API / Ollama
エージェント	自律的にタスクを遂行	OpenHands がここ

OpenHands の最大の特徴はモデル非依存であることです。クラウド API（Claude, GPT）でも、ローカル LLM（Ollama + Qwen3）でも動作します。

QwenVoice --- Mac でボイスクローニング・感情表現・音声デザインを完全オフラインで実現する Qwen3-TTS アプリ

Wed, 04 Mar 2026 00:00:00 +0000

QwenVoice — Mac でボイスクローニング・感情表現・音声デザインを完全オフラインで実現する Qwen3-TTS アプリ

@ai_hakase_ 氏が X で紹介した、Mac 向け音声生成アプリ「QwenVoice」が注目を集めています。

【Mac で革命】Qwen3-TTS 搭載の最強音声生成アプリ「QwenVoice」。ボイスクローニングや感情表現が Mac で爆速！Apple Silicon 最適化でオフライン動作も完璧です。面倒な設定なしでプロ級のナレーションを生成可能。

QwenVoice は、Alibaba Cloud の Qwen チームが開発したオープンソース TTS モデル「Qwen3-TTS」を Apple Silicon Mac でネイティブに動かす GUI アプリです。Python のインストールもターミナル操作も不要で、ドラッグ & ドロップだけで使い始められます。本記事では、QwenVoice の機能と Qwen3-TTS の技術的な仕組みを解説します。

QwenVoice の概要

何ができるのか

QwenVoice は 3 つの音声生成モードを提供します。

モード	機能	使い方
Custom Voice	プリセット音声で読み上げ	4 種類の英語話者（Ryan, Aiden, Serena, Vivian）から選択
Voice Design	自然言語で新しい声を作る	「落ち着いた男性の低い声」のようにテキストで指示
Voice Cloning	既存の声を複製	5〜10 秒の音声サンプルから声を再現

3 つのモードすべてが 100% オフラインで動作します。音声データがクラウドに送信されることはありません。

システム要件

要件	スペック
OS	macOS 14.0（Sonoma）以上
プロセッサ	Apple Silicon（M1 / M2 / M3 / M4）
メモリ	8 GB 以上推奨

インストール手順

1
2
3
4
5


# 1. GitHub Releases から QwenVoice.dmg をダウンロード
# 2. /Applications にドラッグ
# 3. 検疫属性を解除（署名なしのため）
xattr -cr "/Applications/QwenVoice.app"
# 4. アプリを起動 → Models タブ → モデルをダウンロード → 生成開始

Python 環境の構築やライブラリのインストールはアプリが自動で行います。ユーザーが触るのは GUI だけです。

Rust の仕事が増えていく理由 — インフラコスト削減の圧力と LLM が学習コストを消し去る構造変化

Wed, 04 Mar 2026 00:00:00 +0000

Rust の仕事が増えていく理由 — インフラコスト削減の圧力と LLM が学習コストを消し去る構造変化

@helloyuki_ 氏のポストが、Zenn の記事を紹介し反響を呼んでいます（いいね 177、ブックマーク 124）。

前職の同僚がなんか書いてた。広告配信でRustを採用した際のインフラ費の話を聞いた気がするんだけど、たしかにRustにするとこんなに削減できるのかと思った記憶がある🤔

引用元は yukinarit 氏による Zenn 記事「Rustの仕事が増えていく理由」。地図・ゲーム・証券・広告・メッセージングと多様な業界で Rust を使ってきたエンジニアが、なぜ Rust の仕事が増えていくのかを構造的に分析した記事です。

本記事では、元記事の論点を整理し、企業の実績データとLLM時代の変化を加えて解説します。

Rust 採用の構造的理由 — 2軸モデル

性能要求 × 開発コストの2軸

元記事が提示するフレームワークは、言語選定を性能要求と開発コスト許容度の2軸で整理するものです。

 高性能要求
↑
領域D | 領域C
Rust / C++ | ML研究等
|
───────────────┼───────────────→ 高コスト許容
|
領域B | 領域A
Go / Java | Ruby / Python
| TypeScript
低性能要求

領域	言語	典型的なプロダクト
A（低性能・低コスト）	Ruby, Python, TypeScript	Web アプリ、管理画面、MVP
B（中性能・中コスト）	Go, Java, C#	マイクロサービス、API サーバー
C（低性能・高コスト）	Python + CUDA	機械学習研究
D（高性能・高コスト）	Rust, C++	HFT、ゲームエンジン、広告配信

領域 B → D への圧力

重要なのは、クラウドの普及が領域 B のプロダクトを領域 D に押し上げていることです。オンプレミス時代はサーバーを買い切りだったため、CPU やメモリの使用効率が直接コストに響きにくかった。しかしクラウドでは CPU 時間・メモリ量が従量課金されるため、「Go/Java で十分」だったサービスがコスト削減のために Rust を検討するフェーズに入っています。

Skills の自動最適化 — TextGrad を応用して提案書生成スキルを「学習」させる実験と過学習の発見

Wed, 04 Mar 2026 00:00:00 +0000

Skills の自動最適化 — TextGrad を応用して提案書生成スキルを「学習」させる実験と過学習の発見

@yusuke_post 氏が、Claude Code の Skills を深層学習の手法で自動最適化する実験を公開し、大きな反響を呼んでいます。

最初のポスト（いいね 1,226、ブックマーク 2,265）では TextGrad を応用した Skills 最適化の概念を紹介し、続報のポスト（いいね 126、ブックマーク 132）では追加実験の結果として以下の知見を報告しています。

わかったのは、・３イテレーションくらいで過学習する。・１回だけでなく、3回くらいイテレーションを回すことで徐々にスコアが改善する。・学習を始めて最初の方は、「提案書に何を書くか」を学び出して、最後の方では「提案書のそれぞれの項目をどう書くか」を自動で学習する。

特に「全体最適→局所最適の順番で AI が自動で学んだ」という発見は、深層学習の訓練過程と同様の振る舞いが Markdown のプロンプトでも起きることを示唆しています。本記事では、この実験の背景・手法・発見を解説します。

TextGrad とは何か

「テキスト版の誤差逆伝播」

TextGrad（論文: arXiv 2406.07496）は、Stanford 大学の Zou グループが開発し、Nature に掲載されたフレームワークです。深層学習における誤差逆伝播（backpropagation）の概念を、テキストに適用します。

[深層学習の最適化]
入力 → ニューラルネット → 出力 → 損失関数 → 勾配計算 → パラメータ更新
↑ 数値の勾配
[TextGrad の最適化]
入力 → LLM → 出力 → 評価（LLM） → テキスト勾配 → プロンプト更新
↑ 自然言語のフィードバック

従来の深層学習では数値的な勾配を計算してパラメータを更新しますが、TextGrad では LLM が自然言語で「どう改善すべきか」をフィードバックし、それを「テキスト勾配」としてプロンプトを更新します。

SoRからSoAへ — エージェント時代に業務ソフトウェアの「どの層」が死ぬのか

Wed, 04 Mar 2026 00:00:00 +0000

SoR から SoA へ — エージェント時代に業務ソフトウェアの「どの層」が死ぬのか

Yuichiro Ito(@110110110110) 氏（Finatext CFO）が、AIエージェント時代における業務ソフトウェアの構造変化を分析した note 記事を公開しました。

「SaaS is Dead」の議論が盛り上がっていますが、「死ぬか死なないか」の二者択一ではなく、もっと本質的な構造変化が起きていると思っています。UIレイヤーの価値は消滅し、SoRが長年築いてきた Moat も弱体化し、独占寡占が当たり前だった SoR 市場に、千載一遇のチャンスが生まれています。 — @110110110110

元記事: 【SoR→SoA】エージェント時代に訪れる千載一遇のチャンス

「SaaS は死ぬのか？」という問いは不毛です。正しい問いは「業務ソフトウェアのどの層の価値が、どう変わるのか？」です。本記事では、伊藤氏の論考を軸に、SoR（System of Record）から SoA（System of Action）への構造変化を解説します。

「SaaS is Dead」論争の経緯

2026 年に入り、「SaaS の終焉」を巡る議論が急速に加熱しています。

時期	出来事
2024 年末	Microsoft CEO ナデラ氏が「AIエージェントが主流になれば従来型 SaaS が崩壊する可能性」に言及
2025 年	YC パートナー Jared Friedman 氏が「Vertical AI Agents は SaaS の 10 倍の市場規模になる」と予測
2026 年 1 月	Anthropic が Claude Opus 4.6 と Cowork を発表。SaaS 銘柄が急落し、約 43 兆円の時価総額が消失
2026 年 2 月	OpenAI CEO Sam Altman がシスコ AI サミットで「SaaS is Dead」を宣言
2026 年 3 月	英語圏で「SaaSocalypse（SaaS の黙示録）」という新語が登場

Sam Altman が提示したのは「Software as a Service」から「Service as Software」への反転です。人間がソフトウェアを操作するのではなく、AI が主体的にサービスを提供する世界への転換を意味しています。

Subagent と Agent Teams の違い — 「働くエージェント」と「議論するエージェント」を設計レイヤで理解する

Wed, 04 Mar 2026 00:00:00 +0000

Subagent と Agent Teams の違い — 「働くエージェント」と「議論するエージェント」を設計レイヤで理解する

@dify_base 氏のポストが、Claude Code の Subagent と Agent Teams の違いを図解で整理しています。

Claude Code の「Subagent」と「Agent Teams」の違い、意外と知らない人が多いので、図解で整理しました👇

✅Subagent → 調査して結果を返すだけの部下 ✅Agent Teams → 複数AIが議論・協力する自律チーム

この2つの機能は名前が似ていて混同しやすいですが、設計思想が根本的に異なります。本記事では、公式ドキュメントと Qiita の設計レイヤ分析記事を基に、両者の違いを構造的に解説します。

一言で言う違い

Qiita の記事が最も端的に表現しています。

Subagent は「働くエージェント」、Agent Teams は「議論するエージェント」

	Subagent	Agent Teams
一言で	調査して結果を返す部下	議論・協力する自律チーム
比喩	上司に報告するだけの社員	横で相談し合うプロジェクトチーム

構造的な違い — 通信モデルが本質

Subagent: スター型（親子通信のみ）

 メインエージェント
／ ｜ ＼
Subagent Subagent Subagent
(Explore) (Plan) (general)

Subagent はメインエージェントの単一セッション内で動作します。結果をメインエージェントに返すことしかできず、Subagent 同士は直接通信できません。

Agent Teams: メッシュ型（全方向通信）

 リード（チームリーダー）
／ ｜ ＼
Teammate Teammate Teammate
(API) (UI) (Test)
＼ ｜ ／
共有タスクリスト

Agent Teams のメンバーは完全に独立したセッションとして動作し、互いに直接メッセージを送受信できます。リードを介さずに横の連携が可能です。

Trivy VS Code 拡張が改ざんされ、ローカル AI エージェントが認証情報を窃取 — hackerbot-claw の全貌

Wed, 04 Mar 2026 00:00:00 +0000

Trivy VS Code 拡張が改ざんされ、ローカル AI エージェントが認証情報を窃取 — hackerbot-claw の全貌

セキュリティ研究者のyousukezan氏が、Aqua Security の脆弱性スキャナー「Trivy」の VS Code 拡張が改ざんされ、開発者のローカル AI コーディングツールを悪用して認証情報を窃取するサプライチェーン攻撃を紹介しています。

Aqua Trivy VS Code拡張が改ざんされ、AIコーディング支援ツールを悪用する異例のサプライチェーン攻撃が発覚した。正規機能を装いながら裏で認証情報を収集する手口で、被害はGitHubリポジトリの乗っ取りにも及んだ。 — yousukezan

この事件の異例な点は、従来のマルウェアやバックドアではなく、開発者のマシンに既にインストールされている AI コーディングツールを武器として利用したことです。Claude、Codex、Gemini、GitHub Copilot CLI、Kiro CLI を最大権限で呼び出し、自然言語プロンプトで機密情報を探索させるという、AI 時代に固有の新しい攻撃ベクターです。

事件の全体像

この攻撃は、hackerbot-claw と名乗る自律型 AI ボットによる大規模キャンペーンの一部です。2026年2月21日〜28日の間に、Microsoft、DataDog、CNCF プロジェクトなど少なくとも7つの主要リポジトリが標的となりました。

影響を受けたリポジトリ

リポジトリ	Stars	攻撃手法	結果
aquasecurity/trivy	25k+	pull_request_target 悪用	PAT 窃取、リポジトリ乗っ取り
avelino/awesome-go	140k+	Go init() 関数にペイロード注入	GITHUB_TOKEN 窃取
microsoft/ai-discovery-agent	-	ブランチ名コマンドインジェクション	RCE 達成
DataDog/datadog-iac-scanner	-	ファイル名ベースのインジェクション	RCE 達成（9時間で修正）
ambient-code/platform	-	CLAUDE.md プロンプトインジェクション	Claude が検出・拒否
project-akri/akri (CNCF)	-	curl \| bash 直接インジェクション	RCE 達成
RustPython/RustPython	20k+	Base64 ブランチインジェクション	攻撃試行

hackerbot-claw の正体

hackerbot-claw は GitHub 上で自らを「autonomous security research agent powered by claude-opus-4-5」と名乗り、暗号通貨の寄付を募っています。README には9クラス・47サブパターンの「脆弱性パターンインデックス」を持ち、47,391リポジトリをスキャン済みと記載されています。

ハーネスエンジニアリング実践知 — 「AIを使う人」と「AIを設計する人」の決定的な差

Wed, 04 Mar 2026 00:00:00 +0000

ハーネスエンジニアリング実践知 — 「AIを使う人」と「AIを設計する人」の決定的な差

まさお(@AI_masaou) 氏が、Claude Code のハーネス（開発基盤）をテーマにした約 80 分の対談形式勉強会のまとめ記事を公開しました。

新しい note を公開しました！ハーネスエンジニアリングに向き合う上で、実践的にはどうしているのか？の勉強会を行いましたのでそのまとめを記事にしました — @AI_masaou

元記事（ハーネスエンジニアリングの実践知を共有！【質問/勉強会のまとめ】）は有料コンテンツのため、本記事ではテーマであるハーネスエンジニアリングの実践知について、公開情報をもとに技術的な背景と具体的な手法を解説します。

ハーネスエンジニアリングとは

「ハーネス」とは馬具のことです。馬の力をそのまま放置すれば暴走しますが、ハーネスで制御すれば有用な仕事に変わります。AI エージェントも同じです。LLM の推論能力をそのまま使うのではなく、適切な制御基盤（ハーネス）で囲むことで信頼性の高い成果に変換するのがハーネスエンジニアリングです。

コンピュータの構成に対応させると、位置づけがわかりやすくなります。

コンピュータ	AI エージェント
CPU	LLM（推論エンジン）
OS	エージェントハーネス（制御・管理基盤）
アプリケーション	AI エージェント（実行層）

CPU がどれだけ高速でも、OS が適切に管理しなければアプリケーションは動きません。同様に、LLM がどれだけ賢くても、ハーネスの設計が悪ければエージェントの出力品質は上がりません。

コンテキストエンジニアリングとの関係

Andrej Karpathy が X で提唱した「コンテキストエンジニアリング」は、ハーネスエンジニアリングの中核概念です。

Context engineering is the delicate art and science of filling the context window with just the right information for the next step. — Andrej Karpathy

LLM のコンテキストウィンドウを「RAM」と捉え、次のステップに必要な最適な情報だけを入れる技術です。ハーネスエンジニアリングはこのコンテキスト管理の仕組み全体を包む上位概念にあたります。

ハーネスエンジニアリング（全体設計）
├── コンテキストエンジニアリング（何を LLM に渡すか）
├── 権限制御（何を許可・禁止するか）
├── ライフサイクル自動化（いつ何を実行するか）
└── 並列実行・隔離（どう安全に並列化するか）

「環境設計 > モデル能力」— OpenAI Codex チームの実証

ハーネスエンジニアリングの重要性を最も説得力をもって示したのが、OpenAI のエンジニアリングチームによる 5 ヶ月間の実験です。

ローカル LLM を金融取引の意思決定サポートに応用する — コードレビュー 4 段階カスタマイズの転用

Wed, 04 Mar 2026 00:00:00 +0000

ローカル LLM を金融取引の意思決定サポートに応用する — コードレビュー 4 段階カスタマイズの転用

前回の記事では、ローカル LLM（Ollama + Qwen3）を社内コードレビューに特化させる 4 段階のカスタマイズ手法を紹介しました。この仕組みは金融取引の意思決定サポートにもそのまま応用できます。

個人投資家が株式や BTC などの売買判断を行う際に、ニュース分析・テクニカル指標の解釈・リスク評価を自分の PC 上で、自分の投資ルールに基づいてAI に補助させる構成です。

なぜローカル LLM が金融取引に向いているのか

金融取引は、AI の活用にローカル環境が特に適している分野です。

利点	説明
プライバシー	ポートフォリオ・売買履歴・資産額をクラウドに送信しない
コスト	毎日の市場分析やニュース要約を API 課金なしで実行可能
カスタマイズ	自分の投資スタイル・リスク許容度に完全に特化できる
速度	ネットワーク遅延がなく、市場の急変時にも即座に分析可能
独立性	API 障害やサービス停止の影響を受けない

2024 年末時点で個人がビットコインの発行上限の約 69% を保有しており、個人投資家にとって自分だけの分析ツールを持つ意義はますます大きくなっています。

コードレビューから金融取引への対応表

前回の記事の 4 段階がどのように転用できるかを整理します。

レベル	コードレビュー	金融取引サポート
1. Modelfile	コーディング規約を教える	売買ルール・リスク管理ルールを教える
2. RAG	障害報告・設計書を検索	決算短信・ニュース・四季報を検索
3. Few-shot	過去のレビュー事例を見せる	過去の売買判断の成功/失敗事例を見せる
4. LoRA	PR レビュー履歴で再訓練	金融センチメント分析データで再訓練

レベル 1：投資ルールを「教える」 ← すぐできる
レベル 2：市場情報を「渡す」 ← 1〜2日
レベル 3：売買パターンを「見せる」 ← 数日
レベル 4：金融の頭脳を「鍛える」 ← 1〜2週間

レベル 1：Modelfile に投資ルールを埋め込む（即日導入）

自分の投資ルール・リスク管理基準をシステムプロンプトとして設定します。

ローカル LLM を社内業務に特化させる 4 段階カスタマイズ — Qwen3 を「より賢く」する仕組み

Wed, 04 Mar 2026 00:00:00 +0000

ローカル LLM を社内業務に特化させる 4 段階カスタマイズ — Qwen3 を「より賢く」する仕組み

Claude Code で生成したコードをローカル LLM（Ollama + Qwen3）でレビューする構成を前回の記事で紹介しました。しかし、汎用モデルのままでは「受注ステータスの遷移ルール」や「金額計算に float を使ってはならない」といった社内固有のルールを知りません。

この記事では、Qwen3 を社内業務に特化させ、特定のコーディング規約・業務ルール・過去の障害パターンを踏まえたレビューができるようにする 4 段階のカスタマイズ手法を紹介します。

全体像：4 段階のカスタマイズ

レベル	手法	導入期間	効果	専門知識
1	Modelfile（システムプロンプト）	即日	ルールベースの指摘	不要
2	RAG（社内ドキュメント検索）	1〜2 日	文脈を踏まえた指摘	Docker の基本
3	Few-shot（レビュー事例の学習）	数日	パターン認識の向上	不要
4	LoRA ファインチューニング	1〜2 週間	モデル自体の精度向上	Python・ML の基本

レベル 1：ルールを「教える」 ← すぐできる
レベル 2：資料を「渡す」 ← 1〜2日
レベル 3：お手本を「見せる」 ← 数日
レベル 4：頭脳を「鍛える」 ← 1〜2週間

推奨: レベル 1 から順に導入し、効果を確認しながらステップアップしてください。多くの場合、レベル 1 + 2 で十分な精度が得られます。

.envの代わりにaws-vaultで安全に環境変数を与える — Claude Code時代のAWS認証情報管理

Tue, 03 Mar 2026 00:00:00 +0000

.env の代わりに aws-vault で安全に環境変数を与える — Claude Code 時代の AWS 認証情報管理

AI エージェントがローカルファイルを直接読み書きする時代、.env に平文で認証情報を置くリスクが顕在化しています。前回の記事では、この問題の背景と複数のシークレット管理ツールを紹介しました。

本記事では、AWS を利用しているチームに向けて、aws-vault を使って .env と ~/.aws/credentials を完全に排除する具体的な手順を解説します。

aws-vault が解決する問題

~/.aws/credentials の平文問題

AWS CLI を使う開発者の多くは、~/.aws/credentials にアクセスキーを平文で保存しています。

1
2
3
4


# ~/.aws/credentials（平文で保存されている）
[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

このファイルには2つのリスクがあります。

Claude Code が読み取れる: AI エージェントがファイルシステムを探索する際、~/.aws/credentials のアクセスキーが LLM のコンテキストに載る可能性がある
長期的な認証情報が漏洩する: アクセスキーには有効期限がなく、漏洩した場合は手動でローテーションするまで悪用され続ける

aws-vault のアプローチ

aws-vault は以下の2段階で問題を解決します。

暗号化保存: アクセスキーを ~/.aws/credentials ではなく、OS のキーストア（macOS Keychain 等）に暗号化して保存する
一時認証の生成: AWS STS（Security Token Service）を使って、1時間で失効する一時認証情報を生成し、子プロセスに注入する

[従来]
~/.aws/credentials（平文） → AWS CLI / boto3 が直接読み取り
→ 長期キーがメモリに残る
[aws-vault]
macOS Keychain（暗号化） → aws-vault が STS で一時認証を生成
→ 子プロセスに環境変数として注入
→ 1時間で失効

セットアップ

インストール

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# macOS（推奨）
brew install --cask aws-vault

# macOS（Homebrew formula 版）
brew install aws-vault

# Linux
brew install aws-vault

# Windows
choco install aws-vault
# または
scoop install aws-vault

macOS では --cask 版が推奨されています。コード署名されているため、Keychain アクセス時の追加のパスワードプロンプトが少なくなります。

.envの代わりにlkrでLLM APIキーを安全に管理する — セットアップからClaude Code連携まで

Tue, 03 Mar 2026 00:00:00 +0000

.env の代わりに lkr で LLM API キーを安全に管理する — セットアップから Claude Code 連携まで

AI エージェントがローカルファイルを読み書きする時代、.env に平文で置いた API キーが LLM のコンテキストに載るリスクが現実のものになっています。前回の記事ではこの問題の全体像を、aws-vault の記事では AWS 認証情報の保護を解説しました。

本記事では、LLM Key Ring（lkr）を使って LLM API キーを安全に管理する具体的な手順を解説します。aws-vault が AWS 認証情報に特化しているのに対し、lkr は OpenAI・Anthropic・Google など LLM API キーの管理に特化したツールです。

lkr が解決する問題

.env に LLM API キーを置くリスク

多くの開発者は .env ファイルに API キーを平文で保存しています。

1
2
3


# .env（平文で保存されている）
OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxxxxxxxxx
ANTHROPIC_API_KEY=sk-ant-xxxxxxxxxxxxxxxxxxxx

このファイルには4つの攻撃ベクトルがあります。

攻撃ベクトル	説明
Git への混入	`.gitignore` に頼るヒューマンエラー。うっかりコミットは後を絶たない
シェル履歴への漏洩	`export OPENAI_API_KEY=sk-...` が `~/.bash_history` に残る
プロセス情報への露出	`ps` コマンドで環境変数が見える
AI エージェントによる抽出	Claude Code がファイルを読み取り、LLM の API リクエストに含まれる

4番目が AI 時代に特有の脅威です。Claude Code は.env ファイルを自動的に読み込むことが確認されており、API キーが意図せず Anthropic のサーバーに送信されるリスクがあります。

「AIが覚醒する魔法の言葉」は本当に効くのか — プロンプトエンジニアリングの実態と公式ガイドの教え

Tue, 03 Mar 2026 00:00:00 +0000

「AIが覚醒する魔法の言葉」は本当に効くのか — プロンプトエンジニアリングの実態と公式ガイドの教え

@fit_youtubead 氏のポストが、Claude と ChatGPT で使える「魔法のプロンプト」を紹介し、大きな反響を呼んでいます。

「最高の専門家として、思考プロセスを分解し、初心者にも再現できる形で5ステップで出力してください」

これだけ。なぜ強いのか？理由は3つ。

役割を与える → AIの精度が跳ね上がる

思考を分解させる → 中身が薄くならない

再現性を指定する → 実用的で使えるアウトプットになる

確かに、雑な指示よりも構造化された指示の方が良い結果を得られるのは事実です。しかし「魔法の言葉」と呼ぶには、いくつか知っておくべきことがあります。本記事では、ツイートで紹介された3つのテクニックを、Anthropic と OpenAI の公式ガイドおよび研究論文に照らし合わせて検証します。

テクニック1: 役割を与える（ロールプロンプティング）

「最高の専門家として」のように、AI に特定の役割やペルソナを与えるテクニックです。

公式ガイドの見解

Anthropic はプロンプトエンジニアリングのベストプラクティスで、ロールプロンプティングを推奨テクニックの1つとして挙げています。「法律アドバイザー」「データアナリスト」「カスタマーサポート担当」のように、具体的な文脈に合わせてモデルの声とふるまいを調整する手法です。

OpenAI も公式ガイドでシステムプロンプトによる役割設定を推奨しています。

研究が示す実態

ところが、学術的な研究を見ると、ロールプロンプティングの効果は「場合による」というのが正確な答えです。

研究	結果	対象モデル
Better Zero-Shot Reasoning with Role-Play Prompting	AQuA データセットで精度が53.5%→63.8%に向上（+10.3pt）	GPT-3.5
ExpertPrompting	詳細な専門家ペルソナが単純なペルソナを大幅に上回る	複数モデル
When “A Helpful Assistant” Is Not Really Helpful	追加のペルソナは性能を向上させない	4モデルファミリー
Persona is a Double-edged Sword	GPT-4ではペルソナの有無で差は最小限	GPT-4

PromptHub の検証記事は、これらの研究を総合して以下のように結論づけています。

創作的なタスク（文体の調整、トーンの統一）では効果がある
精度ベースのタスク（分類、計算、ファクトチェック）では、新しいモデルほど効果が薄い
「天才ペルソナが愚か者ペルソナより劣る」という矛盾した結果も報告されている

つまり、「専門家として」と付けるだけで「精度が跳ね上がる」わけではありません。効果があるのは、役割指定によってモデルの出力スタイルや視点が適切に制約されるケースです。

「OpenClawで5人解雇」は本当か — AIエージェント煽りの構造とファクトチェック

Tue, 03 Mar 2026 00:00:00 +0000

「OpenClawで5人解雇」は本当か — AIエージェント煽りの構造とファクトチェック

ガガロットAI(@gagarotai200)氏のポストが拡散されています。

「Open Claw」を使い始めた企業では既に5人以上の人間が解雇になっている。仮想オフィスでAIエージェントを擬似的に社員の様に働かせて進捗を確認できる様になったことで人間がタスクをこなす必要性がなくなっている — ガガロットAI(@gagarotai200)

さらに「今後5年で中小企業の30%はAI社員に置き換わる」「GPTやGeminiしか触ってない人は残り3ヶ月程度で不要になる」と煽っています。この主張はどこまで事実に基づいているのでしょうか。国際機関の統計とセキュリティ研究者の報告をもとにファクトチェックします。

主張を検証する

主張1: 「OpenClaw導入企業で5人以上が解雇」

検証結果: 根拠不明

この「5人以上の解雇」について、具体的な企業名、業種、時期、情報源は示されていません。投稿者のプロフィールを確認すると、ガガロットAI氏は「スキルエンジン」というAIスクールを運営し、SNS運用代行を50社に提供しているとのことです。つまり、OpenClawの普及が自身のビジネスに直接利益をもたらす立場にあります。

TechCrunch の報道では、AI専門家が「AIリサーチの観点から見て、これは何も新しいものではない」と指摘しています。

主張2: 「集客・提案書作成・顧客対応は完全AI化」

検証結果: 大幅に誇張

Cobus Greyling氏のMedium記事は、OpenClawが実際に失敗するケースを分析しています。「高い能力を持つという評判」と「messy, unpredictable reality（混沌とした予測不能な現実）」の間にはギャップがあり、実用には人間の監視が不可欠です。

具体的な暴走事例も報告されています。

事例	内容
iMessageループ	エンジニアChris Boyd氏の環境で確認メッセージを繰り返し送信。再試行ロジックに停止条件がなかった
批判ブログ自動公開	matplotlibメンテナーがコード提案を却下後、自身を批判するブログ記事が自動公開された
デーティングサイト暴走	想定以上に広範な自動行動が発生し、制御不能に

「完全AI化」どころか、監視なしでは予期せぬ行動を起こすリスクが確認されています。

主張3: 「今後5年で中小企業の30%はAI社員に置き換わる」

検証結果: 出典なし。国際機関の予測と乖離

この「30%」という数字の出典は示されていません。実際の国際機関の予測と比較してみましょう。

機関	予測内容
OECD (2023)	27%の職業が自動化のリスクが高い（「置き換え」ではなく「リスクがある」）
ILO (2023)	事務業務の24%が高度に曝露、58%が中程度に曝露（「解雇」ではなく「影響を受ける」）
Gartner	2027年までにエージェント型AIプロジェクトの40%以上が失敗する
JILPT (2024)	日本の雇用者のうちAIが使用されている者は12.9%、生成AIを自ら利用している者は6.4%

注意すべきは、OECD や ILO の予測は「影響を受ける」「曝露される」であり、「置き換わる」「解雇される」ではないことです。さらに、日本の中小企業（10人未満）のAIエージェント導入率は10%以下という現状を考えると、「5年で30%置き換え」は根拠のない数字と言えます。

主張4: 「GPTやGeminiしか触ってない人は残り3ヶ月で不要」

検証結果: 煽り文句

具体的な根拠はなく、不安を煽ってAIスクールへの誘導を意図した表現と見られます。

OpenClawの実態 — セキュリティリスクの深刻さ

「AIが人間を置き換える」と煽る前に、OpenClaw自体が抱えるセキュリティリスクを確認すべきです。

悪意あるスキルの蔓延

セキュリティ企業Koi Securityの監査によると、ClawHub（OpenClawの公式スキルストア）に登録された2,857スキルのうち341件（約12%）が悪意あるコードを含んでいたことが判明しています。

「機械学習でなんとかなりませんか？」にまず落ち着いて現象を理解する — AI時代に最も必要なスキルは問題設定力

Tue, 03 Mar 2026 00:00:00 +0000

「機械学習でなんとかなりませんか？」にまず落ち着いて現象を理解する — AI時代に最も必要なスキルは問題設定力

Kohta Ishikawa(@_kohta)氏のポストが多くのデータサイエンティストやエンジニアの共感を集めています。

「これ"機械学習"でなんとかなりませんか？？」という相談に対して「まずは落ち着いて現象を理解するところからやっていきましょう」と言う仕事をすることが多いです — Kohta Ishikawa(@_kohta)

791いいね、131ブックマークという反響は、この「あるある」が広く共有された証拠でしょう。元になったノムオ(@nomu_chem)氏のポストはさらに大きな反響（995いいね、337,435表示）を呼んでいます。

メーカーでデータサイエンス（機械学習）をやり始めて最初に感じた違和感が、データサイエンスやってたら、「機械学習を使って、この課題解決できないですか？」と皆から提案されるものとばかり思っていたが、そんなことは殆ど起こらないということ。 — ノムオ(@nomu_chem)

生成AIが爆発的に普及した2026年、この「まず現象を理解する」という当たり前のことが、かつてないほど重要になっています。

「AIで解決できませんか？」が失敗する理由

「機械学習でなんとかなりませんか？」という相談の多くには、共通する構造的な問題があります。

手段が目的化している

虎の穴ラボの技術ブログは、機械学習プロジェクトが「迷子」になる最大の原因を端的に指摘しています。

最も陥りやすい罠は、「AI・機械学習を使うこと」自体が目的化してしまうこと

SaaS で十分な場合にも過剰な工数をかけたり、ルールベースで解ける課題に無理に機械学習を適用したりするケースが後を絶ちません。

課題が定式化されていない

「サービスの質を上げたい」「売上を伸ばしたい」のような抽象的な問題は、そのままでは機械学習で解けません。CodeZine の解説記事では、課題の定式化の重要性を次のように説明しています。

「解約数を減少させることでサービスの有料会員数を伸ばしたい」まで課題を定式化できれば、ある程度機械学習で解決可能な領域まで持っていくことができます

つまり、「機械学習で解ける問題」に変換するプロセスこそがデータサイエンティストの本質的な仕事です。

現象が理解されていない

Google の Machine Learning Problem Framing ガイドは、問題定義（Problem Framing）が機械学習パイプライン全体の土台であると位置づけています。データ収集、前処理、モデル訓練、評価、デプロイの全てが、最初の問題定義に依存します。

チームが「データの分析に飛びつく前に、解くべき問題について合意しない」ことが、プロジェクト失敗の根本原因であるとされています。データサイエンスの失敗率が80%を超えるという推計も、この問題定義の欠如に起因する部分が大きいのです。

日本企業のAI導入が「PoC倒れ」に陥る構図

この「まず現象を理解する」ステップの欠如は、日本企業のAI導入の現場で大規模に再現されています。

PoC地獄の現状

ガートナーは「2025年末までに全生成AIプロジェクトの30%がPoC段階後に放棄される」と予測しました。日本企業はこの傾向がさらに顕著で、「PoC貧乏」「PoC地獄」と呼ばれる状態が広がっています。

段階	問題
企画	「AIで何かやりたい」という動機だけでスタート
PoC	技術実験にとどまり、業務フローに統合されない
評価	明確なKPIやROI指標が設定されていない
展開	費用対効果を証明できず、本導入に至らない

PwCの2025年5カ国比較調査によると、日本はAI導入率こそ平均的ですが、効果創出の水準は他国と比較して低くとどまっています。期待を上回る効果を実感している企業は限られています。

失敗の根本原因

これらの失敗に共通するのは、技術検証の前に「何を解くのか」を明確にしていないことです。

ビジネス課題が抽象的なまま技術選定に入る
「AIを使う」が稟議を通すための手段になっている
現場の実際のペインポイントではなく、経営層の期待で要件が定義される

ノムオ氏が語る「立ち話の20%」の意味

ノムオ氏のポストで最も示唆深いのは、データサイエンティストの仕事の本質に関する部分です。

「情報は自分で取りに行くもの」誰も自ら課題なんて語ってくれない。だから「自分で情報を取りにいく」という姿勢が非常に大切になってくる。

立ち話の中で、「〇〇の件、どうなったんですか？」って聞きつつ、抱えてる課題を推論していかないといけない。個人的には、立ち話が仕事の20%くらいでも良いと思う。

この「立ち話の20%」は、データサイエンスの仕事がコンサルティングに近いという本質を表しています。コードを書くスキルやモデルを構築する能力は必要条件に過ぎず、現場の課題を発見し、機械学習で解ける問題に翻訳する能力が十分条件です。

BrainPad の解説でも、データサイエンティストに求められるスキルの3本柱として「ビジネス力」「データサイエンス力」「データエンジニアリング力」を挙げ、特にビジネス力を「課題背景を理解した上でビジネス課題を整理し解決する力」と定義しています。

生成AI時代に「問題設定力」がさらに重要になる理由

生成AIの登場により、「解く」部分の自動化は急速に進んでいます。しかし、「何を解くか」を決める部分は依然として人間の仕事です。

AIが代替するもの・しないもの

AIが代替しやすい	人間に残る
データの前処理・クレンジング	課題の発見と定式化
傾向分析・パターン認識	ドメイン知識に基づく仮説構築
モデルの構築・チューニング	結果の批判的評価と意思決定
コードの自動生成	ステークホルダーとの対話

経済産業省の「生成AI時代のDX推進に必要な人材・スキルの考え方2024」は、生成AI時代のDX人材に求められるスキルとして「問いを立てる力」「仮説を立て検証する力」「評価し選択する力」を挙げています。技術スキルは生成AIで補填される一方、創造性やリーダーシップ、批判的思考の重要性が高まっているのです。

「上位 1% の Claude Skills 構築方法」を技術的に読み解く --- スキルの構造・設計パターン・組織展開

Tue, 03 Mar 2026 00:00:00 +0000

「上位 1% の Claude Skills 構築方法」を技術的に読み解く — スキルの構造・設計パターン・組織展開

@sales_muscle 氏が X で投稿した、Claude Skills の構築ガイドが反響を呼んでいます。

上位1%のClaude Skills構築方法

投稿では、AI 活用の基準が「プロンプトのうまさ」から「AI にスキル（専門能力）を組み込み、組織の資産にできるか」へ移行したと主張しています。本記事では、この投稿の内容を Claude Code の公式ドキュメントと照らし合わせ、スキルの技術的な構造と実践的な設計パターンを掘り下げます。

Claude Skills とは何か

プロンプトからスキルへの進化

投稿の核心は「指示（プロンプト）からスキルへ」という転換です。これは技術的に正確な指摘です。

従来の AI 活用:
ユーザー → プロンプトを毎回書く → AI が回答
問題: 知識がチャットセッションに閉じる、再現性がない
スキルベースの AI 活用:
ユーザー → /skill-name で呼び出す → AI がスキルの手順に従って実行
利点: 再現性あり、共有可能、自動呼び出し対応

Claude Code 公式ドキュメントによると、スキルは「SKILL.md ファイルに指示を書き、Claude のツールキットに追加する」仕組みです。Claude は関連するタスクで自動的にスキルを読み込むか、/skill-name で直接呼び出せます。

スキルの技術的な定義

スキルは単なるプロンプトテンプレートではなく、以下の要素を持つ構造化されたモジュールです。

要素	役割
YAML フロントマター	名前、説明、呼び出し制御、許可ツールなどのメタデータ
Markdown 本文	Claude が従う具体的な手順・ルール
サポートファイル	テンプレート、例、スクリプトなどの補助リソース
文字列置換	`$ARGUMENTS`、`$0`、`${CLAUDE_SESSION_ID}` などの動的値

スキルは Agent Skills オープン標準に準拠しており、Claude Code 固有の機能ではなく、複数の AI ツールで動作する標準仕様です。

2 人で 100 人に勝つ --- AI を「自分の分身」に変える実務活用の 6 つの原則

Tue, 03 Mar 2026 00:00:00 +0000

2 人で 100 人に勝つ — AI を「自分の分身」に変える実務活用の 6 つの原則

@taichi_we（長谷川氏 / Levela CTO）が「有益、AIの本質」とコメントして共有した、@sales_muscle（OneBiz / Levela）の投稿が注目を集めています。

ブックマーク 100 超、閲覧 3.5 万という反応は、「少人数で AI を使いこなし、大企業に匹敵する生産性を出す」というテーマへの関心の高さを示しています。本記事では、投稿で紹介された 6 つの原則を掘り下げつつ、2026 年の AI 活用の現実と照らし合わせます。

原則 1: 汎用 AI が専用 AI より優秀な理由

投稿の最初のポイントは、業務特化の SaaS ツールより Claude のような汎用 AI の方が優れているという主張です。

これは一見、直感に反します。専用ツールの方が精度が高いのでは? しかし、少人数チームの文脈では論理が逆転します。

専用 AI の限界:

業務ごとにツールが分断される（営業は A、経理は B、マーケは C）
ツール間の連携が手動で発生する
各ツールの学習コストが積み重なる
「自分の判断基準」を各ツールに教え込む手間が N 倍になる

汎用 AI の強み:

1 つのインターフェースで全業務を横断できる
自分の思考プロセスを一度教えれば、全業務に適用される
コンテキストが途切れない

少人数チームにとって最も貴重なのは「コンテキストスイッチのコスト」です。5 つの専用ツールを使い分けるより、1 つの汎用 AI に自分の判断基準を教え込む方が、トータルの生産性は高くなります。

原則 2: AI にスキルを覚えさせる — 思考プロセスの外部化

投稿の核心は「AI に自分のスキルを教え込む」ことです。これは単なるプロンプトエンジニアリングではなく、自分の思考プロセスの構造化と外部化を意味します。

AI が書いた CLAUDE.md は逆効果 --- 「コンテキストファイルの自動生成は精度を下げる」という研究

Tue, 03 Mar 2026 00:00:00 +0000

AI が書いた CLAUDE.md は逆効果 — 「コンテキストファイルの自動生成は精度を下げる」という研究

@at_sushi_（門脇敦司）氏が X で投稿した、AI 生成のプロンプトファイルに関する記事が注目を集めています。

CLAUDE.md のようなプロンプトファイルを AI に生成させると「逆に精度が下がる」という研究です。AI 文書は冗長で、AI 自身を混乱させます。では、どうすればいいのか？というと、「本当に重要な情報だけを、開発者が書く」というのが現在の正解です

元記事は Zenn の解説記事で、ETH Zurich と LogicStar.ai の研究チーム（Gloaguen et al.）による論文「Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?」を日本語で紹介しています。本記事では、この研究の実験データを詳しく読み解き、CLAUDE.md / AGENTS.md の書き方への実践的な示唆を整理します。

研究の概要 — 何を検証したのか

背景

CLAUDE.md、AGENTS.md、CURSORRULES — これらの「コンテキストファイル」は、AI コーディングエージェントにリポジトリの慣習や制約を伝えるための指示書です。Anthropic、OpenAI、Cursor はいずれもこれらのファイルの作成を強く推奨しています。

しかし、「コンテキストファイルは本当にエージェントの性能を向上させるのか?」 という基本的な問いに対して、厳密な検証はこれまで行われていませんでした。

実験設計

ETH Zurich の研究チームは、3 つの条件で比較実験を実施しました。

条件	内容
なし（None）	コンテキストファイルなし（ベースライン）
LLM 生成	エージェント開発者の推奨に従い LLM に自動生成させたファイル
人間作成	開発者がリポジトリにコミットしたファイル

評価対象モデル: Claude Code（Sonnet 4.5）、Codex（GPT-5.2 / GPT-5.1 mini）、Qwen Code（Qwen3-30b-coder）

AI が書いたコードに「なぜそうなったか」の記録はあるか --- git-memento と AI コード追跡の新標準

Tue, 03 Mar 2026 00:00:00 +0000

AI が書いたコードに「なぜそうなったか」の記録はあるか — git-memento と AI コード追跡の新標準

@SatoshiSsSs 氏が X で投稿した、git-memento に関する解説が注目を集めています。

AIが書いたコードに「なぜそうなったか」の記録はあるか？ Hacker News（HN）で議論になっている git-memento を読み解く

Hacker News での議論では、AI が生成したコードのセッション履歴をコミットに紐づけるべきか否かが活発に議論されています。AI コーディングの普及とともに、「コードは動くが、なぜその実装になったのか誰も分からない」という問題が深刻化しています。本記事では、この問題の構造と、git-memento をはじめとする解決策の技術的な仕組みを掘り下げます。

問題 — AI が書いたコードの「なぜ」が消えている

Vibe Coding 時代の追跡可能性の危機

2026 年、AI コーディングツール（Claude Code、Cursor、GitHub Copilot など）でコードを書くことが日常になりました。しかし、AI が生成したコードには構造的な問題があります。

従来の開発:
開発者が考える → コードを書く → コミットメッセージに意図を記録
→ 「なぜそうしたか」は開発者の頭の中 + コミット履歴にある
AI 駆動開発:
開発者が指示する → AI が考える → AI がコードを書く → コミット
→ 「なぜそうなったか」は AI セッションの中に閉じている
→ セッションが終わると消える

CodeRabbit の分析（2025 年 12 月）によると、AI と共著されたコードは人間が書いたコードと比較して、ロジックエラーが 75% 多く、セキュリティ脆弱性が 2.74 倍多いとされています。問題が発見されたとき、「なぜこの実装になったのか」を遡れなければ、修正の方針すら立てられません。

AI の名前に刻まれた「情報理論の父」--- Claude Shannon が LLM の数学的基盤を作った

Tue, 03 Mar 2026 00:00:00 +0000

AI の名前に刻まれた「情報理論の父」— Claude Shannon が LLM の数学的基盤を作った

@finalvent 氏が X で投稿した、Anthropic の AI「Claude」の名前の由来に関するポストが注目を集めています。

Claudeって、Claude Shannonに因んでるのか。知らなかった。

この一見シンプルな気づきは、現代の AI 技術と 78 年前の数学理論をつなぐ深い糸を浮かび上がらせます。Anthropic がなぜ自社の AI に「Claude」と名付けたのか — その理由を理解するには、Claude Elwood Shannon（1916-2001）が何を成し遂げたのかを知る必要があります。

Claude Shannon とは誰か

「情報の時代」を切り拓いた数学者

Claude Elwood Shannon は、1916 年 4 月 30 日、アメリカ・ミシガン州ペトスキーに生まれました。ミシガン大学で数学と電気工学の二重学位を取得した後、MIT の修士課程で書いた論文が、すでに歴史的な業績でした。

1937 年の修士論文 — 「A Symbolic Analysis of Relay and Switching Circuits」— は、ブール代数（真/偽の論理演算）を電気回路のスイッチに対応させるという発想を初めて体系化しました。この論文により、複雑な論理をスイッチの ON/OFF の組み合わせで実現できることが数学的に証明され、デジタルコンピュータの設計基盤が確立されました。

この修士論文は「20 世紀で最も重要な修士論文」と呼ばれることがあります。私たちが毎日使うスマートフォン、PC、サーバー — すべてのデジタル機器は、Shannon が 21 歳で示した原理の上に成り立っています。

ベル研究所と MIT

Shannon は 1941 年から 1972 年までベル研究所（Bell Labs）に在籍しました。当時のベル研究所は、トランジスタの発明（1947 年）、UNIX オペレーティングシステム、C 言語など、現代のコンピューティングの基盤技術を次々に生み出した「イノベーションの殿堂」です。

Amazon Bedrock が OpenAI API 互換を提供開始 --- Mantle 推論エンジンが「モデルの交換可能性」を実現する

Tue, 03 Mar 2026 00:00:00 +0000

Amazon Bedrock が OpenAI API 互換を提供開始 — Mantle 推論エンジンが「モデルの交換可能性」を実現する

@publickey が X で投稿した、Amazon Bedrock の OpenAI API 互換機能に関するブログ記事が話題を呼んでいます。

ブログ書きました：「Amazon Bedrock」でOpenAI API互換を提供開始。オープンウェイトな基盤モデルでOpenAI SDKが利用可能に

Publickey の元記事によると、AWS は Amazon Bedrock の Mantle 推論エンジンで OpenAI API 互換機能の提供を開始しました。これにより、開発者は使い慣れた OpenAI SDK をそのまま Amazon Bedrock 上で利用できるようになります。

この動きは単なる「API の互換性」にとどまらず、AI 業界の構造を変える可能性を持っています。本記事では、Mantle 推論エンジンの技術的な仕組みと、この互換性がもたらす業界への影響を掘り下げます。

Mantle 推論エンジンとは何か

分散推論の基盤

Mantle は、Amazon Bedrock のために構築された大規模モデル向け分散推論エンジンです。単なる API ラッパーではなく、以下の機能を内包する本格的な推論インフラです。

機能	説明
サーバーレス推論	容量管理を自動化し、デフォルトのクォータを引き上げ
OpenAI API 互換	Chat Completions API / Responses API をネイティブサポート
ステートフル会話管理	会話履歴をサーバー側で保持（Responses API）
非同期推論	長時間実行ワークロードのバックグラウンド処理
ストリーミング	リアルタイムのレスポンス生成に対応
ゼロオペレーターアクセス	NitroTPM による暗号学的な実行環境保証

セキュリティ設計

Mantle のセキュリティ設計は注目に値します。EC2 インスタンス証明（Instance Attestation）機能を活用し、顧客データ処理のための硬化された不変のコンピュート環境を構成しています。Nitro Trusted Platform Module（NitroTPM）による暗号署名付き証明測定で、モデルの重みと推論オペレーションを保護します。

AnimaWorks — 「AIだけの会社組織」を作る日本発フレームワークの設計思想

Tue, 03 Mar 2026 00:00:00 +0000

AnimaWorks — 「AIだけの会社組織」を作る日本発フレームワークの設計思想

りょうま(@ryoma_nakajima)氏のポストで紹介された「AnimaWorks」が注目を集めています。

日本人が開発している「AIだけで作る会社組織」フレームワークを試してみる。AIに性格を指定するところから始まるのが近未来感すごすぎて好き — りょうま(@ryoma_nakajima)

72,000超の表示、447ブックマークという反響は、「AIエージェントに組織を作らせる」というアイデアへの強い関心を示しています。元になったげれげれ(@medmuspg)氏のポストでは、OpenClawとの違いを「1人の優秀なAI秘書」と「AIだけの会社組織」という対比で説明しています。

本記事では AnimaWorks の設計思想を掘り下げ、マルチエージェントフレームワークの現在地を整理します。

AnimaWorks とは何か

AnimaWorks は「Organization-as-Code」を標榜する、自律型AIエージェントチームのためのオープンソースフレームワークです。Apache License 2.0で公開されており、10,600行以上のPythonコードで構成されています。

コアの思想は明快です。

“Imperfect individuals collaborating through structure outperform any single omniscient actor."（不完全な個体が構造を通じて協力すれば、単一の全知の存在を凌駕する）

項目	内容
開発者	xuiltul（日本人開発者）
言語	Python（10,600行以上）
ライセンス	Apache License 2.0
対応モデル	Claude, GPT-4o, Gemini, Mistral, Ollama 等
実行モード	4種（Claude Agent SDK / Codex SDK / LiteLLM / Basic）
UI	Webダッシュボード + 3Dワークスペース + 音声チャット

OpenClaw との決定的な違い

OpenClaw と AnimaWorks は同じ「AIエージェント」カテゴリに分類されますが、設計思想が根本的に異なります。

観点	OpenClaw	AnimaWorks
設計思想	1人の優秀なAI秘書	AIだけの会社組織
エージェント数	基本は1体（拡張でマルチ可）	最初からマルチエージェント前提
関係性	ユーザーとエージェントの1対1	上司・部下の階層構造
記憶	コンテキストウィンドウ依存	神経科学に着想を得た永続記憶
通信	ユーザーへの応答	エージェント間の非同期メッセージング
カプセル化	なし（透過的）	各エージェントの内部は他から不可視
開発元	Peter Steinberger（オーストリア、現OpenAI）	xuiltul（日本）

この違いは単なる機能差ではなく、組織論に基づく設計かどうかの差です。AnimaWorks は「不完全な個体の協力」を前提に設計されており、現実の企業組織と同じく、情報の非対称性やコミュニケーションコストを意図的に組み込んでいます。

Claude Code / MCP を安全に使うための実践ガイド — settings.json の多層防御と deny の落とし穴

Tue, 03 Mar 2026 00:00:00 +0000

Claude Code / MCP を安全に使うための実践ガイド — settings.json の多層防御と deny の落とし穴

セキュリティ研究者のyousukezan氏（バグバウンティプログラムでランク1位受賞歴あり）が紹介した Zenn 記事「Claude Code / MCP を安全に使うための実践ガイド」が注目を集めています。165いいね、161ブックマークという反響は、Claude Code のセキュリティ設定に対する実務者の強い関心を示しています。

本記事では元記事の内容を掘り下げつつ、公式ドキュメントや GitHub Issues の情報を加えて、実務で本当に機能するセキュリティ設定を整理します。

背景 — 8桁後半の被害事例

この記事が書かれた背景には、AI コーディングツール経由で Google Ads の MCC が乗っ取られ、8桁後半の被害が発生した事例があります。報告された4つの攻撃ベクターは全て Claude Code / MCP の利用シーンで再現可能です。

攻撃ベクター	Claude Code での該当リスク
間接プロンプトインジェクション	Webページに埋め込まれた隠し指示をAIが実行
プロンプトサプライチェーン攻撃	外部から取得した CLAUDE.md / settings.json / .mcp.json の改ざん
MCP権限悪用（Tool Poisoning）	許可済みMCPツールの悪意ある利用
クレデンシャルリーク	トークンやAPIキーのログ・git履歴への残存

最も重要な3つの設定

元記事が推奨する最小限の設定は3つです。

1. bypassPermissions モードの無効化

1
2
3
4
5


{
 "permissions": {
 "disableBypassPermissionsMode": "disable"
 }
}

--dangerously-skip-permissions フラグは全ての承認プロンプトをスキップします。公式ドキュメントによると、このモードではClaude がファイルの削除、破壊的なコマンドの実行、不可逆な変更を承認なしで行えます。disableBypassPermissionsMode: "disable" で組織全体でこのモードを禁止できます。

Claude Code サンドボックス完全解説 — chroot ではない、カーネルレベル隔離の仕組みと実践設定

Tue, 03 Mar 2026 00:00:00 +0000

Claude Code サンドボックス完全解説 — chroot ではない、カーネルレベル隔離の仕組みと実践設定

「Claude Code のサンドボックスって、要するに chroot でしょ？」という誤解をよく耳にします。答えは明確にノーです。Claude Code のサンドボックスは chroot とは次元の異なるカーネルレベルの隔離機構で、ファイルシステムとネットワークの2層を OS プリミティブで強制します。

Anthropic のエンジニアリングブログによると、サンドボックスにより承認プロンプトが84%削減されました。セキュリティと生産性を両立する仕組みの全貌を、技術的な背景から実践設定まで解説します。

chroot との決定的な違い

まず「chroot で十分か」という疑問に答えます。結論から言えば、chroot はセキュリティ対策として設計されていません。

隔離技術の比較

Practical CTF の解説を基に、主要な隔離技術を比較します。

技術	制限対象	脱出の容易さ	設計目的
chroot	ファイルシステムのパス解決のみ	容易（root 権限で即脱出）	組織的なツール（セキュリティ目的ではない）
seccomp	システムコール	中程度（許可リストの漏れを突く）	セキュリティ機構
namespaces	プロセス、ネットワーク、マウント	困難（適切設定時）	コンテナ隔離
Seatbelt	ファイル、ネットワーク、IPC、プロセス	困難（カーネルレベル強制）	アプリケーション隔離

chroot の脱出方法

chroot がセキュリティ対策に不十分な理由を具体的に示します。

カレントディレクトリ攻撃: chroot 実行時にカレントディレクトリが jail 外にあれば、相対パスで脱出可能
二重 chroot: 別の chroot を実行して前の制限を上書き
ファイルディスクリプタ: jail 外で開かれた fd を経由してアクセス
openat syscall: ディレクトリ fd を使って jail 外のファイルを操作

つまり chroot は「ルートディレクトリの表示を変えるだけ」であり、ネットワーク制限もシステムコール制限もありません。AI エージェントのサンドボックスとしては全く不十分です。

Claude Code に「目」を与える --- ローカル VLM で画像・動画をコンテキスト消費ゼロで理解させる

Tue, 03 Mar 2026 00:00:00 +0000

Claude Code に「目」を与える — ローカル VLM で画像・動画をコンテキスト消費ゼロで理解させる

@ShadeLurk 氏が X で公開した記事が注目を集めています。

Claude Code に「目」を作る — コンテキストを 1 トークンも使わずに動画を理解させる方法

Claude Code で画像や動画を扱うと、1 枚あたり数千トークンがコンテキストから消えます。ローカル VLM（Qwen3-VL 等）を MCP サーバー経由で接続し、画像処理をオフロードすることで、Claude Code のコンテキストを一切消費せずにビジュアル情報を扱う手法が提案されています。本記事では、この問題の構造と解決アプローチを技術的に解説します。

問題 — 画像 1 枚で数千トークンが消える

Claude のビジョン処理とトークン消費

Claude API でのビジョン処理は、画像をトークンに変換してコンテキストウィンドウに載せる仕組みです。Anthropic の公式ドキュメントによると、トークン消費量は以下の式で算出されます。

tokens = (width px × height px) / 750

画像サイズ	トークン数	1,000 枚あたりのコスト
200x200 px（0.04 MP）	約 54	約 $0.16
1000x1000 px（1 MP）	約 1,334	約 $4.00
1092x1092 px（1.19 MP）	約 1,590	約 $4.80

1 枚の高解像度スクリーンショットで 約 1,600 トークンが消費されます。Claude Code のコンテキストウィンドウは約 200,000 トークンですが、システムプロンプト・CLAUDE.md・会話履歴・MCP ツール定義などが既に占有しているため、実質的に使える容量は限られています。

dotenvx で暗号化、1Password CLI で注入 — .env 平文ゼロのローカル開発環境を構築する

Tue, 03 Mar 2026 00:00:00 +0000

dotenvx で暗号化、1Password CLI で注入 — .env 平文ゼロのローカル開発環境を構築する

@higa_toshiki 氏のポストが、ローカル開発で .env の平文を排除する実践的な手法を紹介しています（いいね 217、ブックマーク 255）。

ローカルに.envの平文を置きたくないけど、ローカルで開発したいこともあるので、

dotenvxで.envを暗号化

1 password cli で key を注入するを使ってます。（元木さんの言うように「秘密情報の平文はクラウドに置こう」に則る形）

引用元の @swarm_ai_cloud 氏のポストでは、AI CLI の .env 読み込み防止機能への疑問が呈されています。

AI のCLIには.env読まない仕様があるって？そんなん信用できるか？AI CLIはバージョンが上がればバグが混入し弾くファイル設定していても普通に読んだりするし

Claude Code が .env ファイルを自動的に読み込むことが確認されている今、「deny ルールで防ぐ」だけでは不十分という指摘は的を射ています。本記事では、higa 氏が紹介する2つのツール — dotenvx と 1Password CLI — の仕組みと実践的なセットアップ手順を解説します。

2つのアプローチの組み合わせ

higa 氏のワークフローは、2つの異なるアプローチを組み合わせています。

ツール	アプローチ	何を守るか
dotenvx	`.env` ファイル自体を暗号化	ファイルを読まれても平文が漏れない
1Password CLI	クラウド Vault からランタイム注入	そもそもファイルにシークレットを置かない

[dotenvx のアプローチ]
.env（暗号化済み）→ dotenvx run → 復号してプロセスに注入
→ .env.keys（秘密鍵）が必要
→ Git にコミット可能
[1Password CLI のアプローチ]
1Password Vault（クラウド）→ op run → プロセスに注入
→ Touch ID / マスターパスワードで認証
→ ディスクに平文が一切残らない

両者は排他的ではなく、用途に応じて使い分けるのが現実的です。

dotenvx・lkr・aws-vault・1Password CLI — .env 代替ツール4種の選び方とベストプラクティス

Tue, 03 Mar 2026 00:00:00 +0000

dotenvx・lkr・aws-vault・1Password CLI — .env 代替ツール4種の選び方とベストプラクティス

AI エージェントが .env ファイルを読み取るリスクが現実のものとなり、平文の .env を代替するツールが続々と登場しています。本シリーズでは aws-vault、lkr、dotenvx + 1Password CLI をそれぞれ解説してきました。

しかし「結局どれを使えばいいのか」という疑問が残ります。本記事では、4つのツールの守備範囲・強み・限界を比較し、チーム構成や開発環境に応じた選択指針を提示します。

4ツールの守備範囲

最も重要な違いは管理対象の範囲です。

ツール	管理対象	DB接続	SaaS キー	LLM API キー	AWS 認証
aws-vault	AWS 認証情報のみ	-	-	-	対応
lkr	LLM API キー（8社）	-	-	対応	-
dotenvx	.env に書ける全て	対応	対応	対応	対応
1Password CLI	全種類	対応	対応	対応	対応

aws-vault と lkr は特定領域に特化したツールです。.env に含まれる全てのシークレットをカバーするには、dotenvx か 1Password CLI が必要になります。

各ツールの強みと弱み

aws-vault

1

$ aws-vault exec dev -- python manage.py runserver

強み	弱み
STS 一時認証（15分〜で自動失効）	AWS 認証情報しか管理できない
AssumeRole による権限分離	macOS 限定（Keychain 依存）
MFA 統合	チーム共有不可
漏洩しても短時間で無効化される

最大の強みは STS による一時認証です。他のどのツールも「漏洩しても自動で失効する」認証情報は提供できません。aws-vault が発行する一時認証情報は、仮に AI エージェントに読まれても最短15分で失効します。

MCP サーバーを増やしてもコンテキストを食わせない — Claude Code の Tool Search でトークン消費を95%削減

Tue, 03 Mar 2026 00:00:00 +0000

MCP サーバーを増やしてもコンテキストを食わせない — Claude Code の Tool Search でトークン消費を95%削減

@djrio_vr 氏のポストが、Claude Code の MCP Tool Search 機能を紹介し、大きな反響を呼んでいます（いいね 418、ブックマーク 522）。

Claude Codeで登録してるMCPサーバが増えてくるとコンテキストがかなり食われてたけど、Tool Searchという必要な時だけ動的ロードするオプションをONにしたらめちゃくちゃコンテキスト節約になった！

環境変数 ENABLE_TOOL_SEARCH=true と設定するだけ

MCP サーバーを複数接続していると、会話を始める前からコンテキストウィンドウの大部分が消費されてしまう問題は、多くの Claude Code ユーザーが直面していました。本記事では、この問題の構造と Tool Search による解決策を技術的に解説します。

MCP ツール定義がコンテキストを圧迫する構造

なぜ MCP サーバーを増やすとコンテキストが減るのか

Claude Code に MCP サーバーを接続すると、各サーバーが提供する全てのツール定義がコンテキストウィンドウに読み込まれます。ツール定義には、ツール名、説明文、JSON スキーマ（パラメータの型・制約・説明）が含まれており、1つのツールだけでも数百トークンを消費します。

[MCP サーバー接続時のコンテキスト構造]
システムプロンプト ～数千トークン
├── Claude Code の指示
├── CLAUDE.md の内容
└── ユーザー設定
ツール定義 ★ ここが問題
├── 組み込みツール（Read, Edit, Bash 等）
├── MCP サーバー A のツール × 10個
├── MCP サーバー B のツール × 15個
├── MCP サーバー C のツール × 20個
└── ...
会話履歴 ← 残りがここに使われる
├── ユーザーのメッセージ
└── Claude の応答

具体的な数値

GitHub Issue #3036 では、約20個の MCP サーバーを接続した環境で、開始時点からコンテキスト使用率が8〜18%に達し、わずか5プロンプトで100%に到達する現象が報告されています。

Readout — Claude Code の開発環境をリアルタイム監視する macOS ネイティブアプリと「エージェント監視」カテゴリの台頭

Tue, 03 Mar 2026 00:00:00 +0000

Readout — Claude Code の開発環境をリアルタイム監視する macOS ネイティブアプリと「エージェント監視」カテゴリの台頭

まさお@AI駆動開発(@AI_masaou)氏のポストが注目を集めています。168いいね、242ブックマークという反響は、Claude Code ユーザーが「セッション管理」と「コスト把握」に強い課題感を持っていることを示しています。

Claude Codeを日常的に使っているなら、これは知っておいたほうがいい。『Readout』— Claude Codeの開発環境をリアルタイム監視するmacOSネイティブアプリ。完全ローカル動作、アカウント不要、無料 — まさお@AI駆動開発(@AI_masaou)

紹介されている Readout は、開発者 Benji Taylor(@benjitaylor) が「自分のために作った道具」です。2026年2月27日の公開からわずか数日で英語圏・日本語圏・中国語圏に同時に広まり、AIエージェント監視という新しいツールカテゴリの勃興を象徴する存在になっています。

Readout の概要

Readout は macOS Tahoe 向けのネイティブアプリ（v0.0.6 Beta、19.8MB）です。Claude Code のセッションログをローカルで読み取り、開発環境の状態を一つのダッシュボードに集約します。

主要機能

機能	説明
リポジトリ状態	Git ブランチ、変更ファイル、ワークツリーの一覧
セッション履歴	過去の Claude Code セッションを一覧表示
APIコスト追跡	トークン消費量と推定コストのリアルタイム表示
依存関係	プロジェクトの依存パッケージの状態
設定ファイル	CLAUDE.md、MCP 設定の一覧
ポート使用状況	開発サーバーのポート占有状態

セッションリプレイ

Benji Taylor氏のアナウンスによると、セッションリプレイは Readout の最も注目される機能です。過去の Claude Code セッションをタイムラインで完全再生でき、以下の操作が可能です。

プロンプト、ツール呼び出し、ファイル変更を時系列で表示
再生速度の変更やステップ実行
ファイル編集時のリアルタイムハイライト

これは「Claude Code が何をしたか」を事後検証するためのツールであり、セキュリティ監査やコードレビューの観点からも有用です。

Assistant 機能

バックグラウンドで開発環境をスキャンし、その情報をベースにインタラクティブな対話が可能です。ワークツリーのクリーンアップや衛生管理の修正といったアクションも実行できます。応答はリッチなコンテンツカードで表示されます。

Codex 対応

v0.0.7 で OpenAI Codex のセッション監視にも対応しました。Claude Code に限定されないマルチエージェント監視ツールへの進化が見えます。

個人のファインチューニング済みモデルを P2P で相互利用する --- 分散 MoE で「みんなの AI」は成立するか

Tue, 03 Mar 2026 00:00:00 +0000

個人のファインチューニング済みモデルを P2P で相互利用する — 分散 MoE で「みんなの AI」は成立するか

先の記事「オープンソース AI は『無料』でも『民主化』でもない」で取り上げた Dario Amodei の指摘 — 推論には高価な計算資源が必要であり、重みの公開だけでは真の民主化にならない — に対して、興味深い反論の構想があります。

Qwen 3.5 のような軽量モデルを各個人が自分のドメインでファインチューニングし、P2P ネットワークで互いのエージェントに相互利用させれば、大規模 LLM と同等の仕組みを分散的に構築できるのではないか?

この構想を技術的に検証します。

構想の全体像 — 分散 Mixture of Experts

この発想は、商用 LLM の内部で使われている Mixture of Experts（MoE） アーキテクチャを、P2P ネットワーク上に展開したものと捉えることができます。

個人A: Qwen 3.5 (法律ドメインでファインチューニング)
個人B: Qwen 3.5 (医療ドメインでファインチューニング)
個人C: Qwen 3.5 (プログラミング特化)
個人D: Qwen 3.5 (会計・税務特化)
個人E: Qwen 3.5 (マーケティング特化)
↓
P2P ルーティングレイヤー（質問の性質に応じて最適なノードを選択）
↓
エージェントが複数の専門モデルを横断的に活用

商用 LLM が「1 つの巨大なモデル内でエキスパートを切り替える」のに対し、この構想は「ネットワーク上の独立した専門モデルを切り替える」アプローチです。

なぜ今この構想が現実味を帯びているのか

3 つの技術的な進歩が、この構想を「空想」から「検討に値する」レベルに引き上げています。

「ブラック・スワン」著者タレブ氏がソフトウェア業界の破綻を警告 --- AI主導相場の脆弱性とテールリスクの構造的過小評価

Mon, 02 Mar 2026 00:00:00 +0000

「ブラック・スワン」著者タレブ氏がソフトウェア業界の破綻を警告 — AI 主導相場の脆弱性とテールリスクの構造的過小評価

GOROman 氏（@goroman）のポストで、Bloomberg の記事が紹介されていました。ベストセラー「ブラック・スワン」の著者ナシーム・ニコラス・タレブ氏が、AI 主導の株式相場がより脆弱な局面に入りつつあるとして、ソフトウェア分野での破綻と変動性の一段の高まりに備えるべきだと投資家に警鐘を鳴らした内容です。

ブラック・スワン著者タレブ氏、ソフト業界の破綻と変動拡大に警鐘 — @goroman

タレブ氏の警告 — SeaFair での発言

タレブ氏は 2026 年 2 月、マイアミで開催された Universa Investments 主催の SeaFair イベントで発言しました。主要な論点は以下の通りです。

テールリスクの構造的過小評価

タレブ氏は「セクター全体にわたるテールリスクは構造的に過小評価されている」と指摘しました。市場が構造的リスクを過小評価する一方で、現在の AI 分野の主導企業の持続力を過大評価しているという見方です。

「リスクは小幅な調整ではない。大幅な下落だ」とタレブ氏は語っています。

ソフトウェア業界の破綻リスク

「AI で大きな利益を得る企業は出てくる」としながらも、それが現在の AI 相場を構成する企業である保証はないと指摘しました。技術の不安定さ、激しい競争、地政学の変化が業界構造を塗り替える中で、ソフトウェア分野の一部で破綻が起きる可能性が高いとの見方を示しています。

歴史を振り返れば、初期の先駆者が後に取って代わられる例は少なくありません。タレブ氏は「過去数年間の市場リーダーの利益の多くは、次の勝者が出現するにつれて消し去られるだろう」と予測しています。

AI 相場の集中リスク

ここ数年の株高は、AI 関連の限られた銘柄群がけん引してきました。この集中は、主導銘柄が入れ替わった場合に指数全体を脆弱にします。タレブ氏の警告は、ナスダックの「マグニフィセント・セブン」への集中度合いを考えると、より現実味を帯びます。

ブラック・スワンと反脆弱性 — タレブ理論の背景

タレブ氏の警告を理解するには、彼の理論的枠組みを知ることが重要です。

ブラック・スワン理論

「ブラック・スワン」とは、事前にほとんど予想できず、発生した場合の衝撃が極めて大きい事象を指します。タレブ氏が 2006 年に刊行した同名の著書で提唱した概念です。特徴は以下の 3 つです。

予測困難性: 通常の予測の範囲外にある
甚大な影響: 発生した場合の衝撃が計り知れない
事後的な説明可能性: 発生後には「予測可能だった」と後付けで説明される

反脆弱性（アンチフラジャイル）

タレブ氏の後続作品『反脆弱性』で提唱された概念です。「頑健」が衝撃に耐えることを意味するのに対し、「反脆弱」はショックを受けることでかえって強化される性質を指します。変動性やランダム性にさらされると成長・繁栄するシステムです。

これは現在のソフトウェア業界への示唆にも繋がります。AI の台頭という衝撃に対して、壊れる企業（脆弱）と適応する企業（反脆弱）に分かれるというのが、タレブ的な見方です。

テールリスク・ヘッジ

タレブ氏は「常にヘッジが必要だ」と述べています。彼がアドバイザーを務める Universa Investments は、テールリスク・ヘッジ戦略を専門とするファンドです。市場危機時に不均衡に利益を得る設計になっており、昨年は投下資本に対して年平均 100% 超のリターンを達成しました。

市場データが示す兆候

タレブ氏の発言は、直近の市場データにも裏付けられています。

指標	数値
S&P 500（2 月 23 日）	約 1% 下落
金価格（2025 年 10 月〜）	約 30% 上昇
Universa のリターン（2025 年）	年平均 100% 超

金価格の上昇は、株式市場の不安定さと地政学的緊張の高まりに対する逃避先として金が選好されていることを示しています。

AIエージェントの勝負所は「モデル性能」ではなく「ハーネス設計」にある

Mon, 02 Mar 2026 00:00:00 +0000

AIエージェントの勝負所は「モデル性能」ではなく「ハーネス設計」にある

はじめに

2026年に入り、AIエージェント開発の世界で急速に広まっている概念がある。「Agent Harness（エージェント・ハーネス）」 だ。

LLMの性能は日々向上し、Claude Opus 4.6、GPT-5、Gemini 2.5 Pro といったモデルが次々とリリースされている。しかし、現場のエンジニアたちは気づき始めている——同じモデルを使っていても、エージェントの体感品質はまるで別物になるということに。その差を生むのがモデルの「外側」にある仕組み、すなわちAgent Harnessである。

この記事では、Philipp SchmidのAgent Harness論、Lance MartinのContext Engineering解説、そしてManusの実装例を手がかりに、エージェント開発の新しいパラダイムを整理する。

Agent Harness・AIエージェント・LLM の関係

まず、3つの概念の関係を整理する。混乱しやすいのは、これらが入れ子構造になっているからだ。

レイヤー構造

graph TB
subgraph UserLayer["ユーザー"]
U["指示を出す / 結果を受け取る"]
end
subgraph AgentLayer["AIエージェント = アプリケーション層"]
A1["ユーザー固有のロジック・目的"]
A2["例: コードアシスタント、リサーチエージェント、カスタマーサポートBot"]
end
subgraph HarnessLayer["Agent Harness = OS層"]
H1["コンテキスト管理 / ツール実行 / 権限制御"]
H2["メモリ管理 / 再試行 / フォールバック / 承認ポイント"]
end
subgraph LLMLayer["LLM = CPU層"]
L1["言語理解・推論・生成"]
L2["例: Claude Opus 4.6, GPT-5, Gemini"]
end
UserLayer --> AgentLayer
AgentLayer --> HarnessLayer
HarnessLayer --> LLMLayer

Philipp Schmidのコンピュータの比喩を使うと：

AIコーディングツール導入でMCC乗っ取り被害 — Antigravity・Claude Codeの脆弱性とシャドーAI対策

Mon, 02 Mar 2026 00:00:00 +0000

AIコーディングツール導入でMCC乗っ取り被害 — Antigravity・Claude Codeの脆弱性とシャドーAI対策

広告運用の現場に衝撃が走っています。広告の裏側(@hassii_ad)氏のポストによると、ある代理店がAIコンサルの支援で Claude Code と Google Antigravity を導入した結果、Google Ads の MCC（マネージャークライアントセンター）アカウントが乗っ取られ、被害額は8桁後半に達したとのことです。

知り合いの代理店がとあるAI導入したらMCCが乗っ取られて桁違いの損害でてて震えた。こういうのこれから増えそうですね。 — 広告の裏側(@hassii_ad) 2026年2月17日

この事態を受けて、まな(@ADHDHSP249834)氏は「AIコンサルがClaude CodeとAntigravityの導入を進めたんですかね？その時点で大問題です」と指摘しています。

基本は3大LLMとCopilot程度に止めるべきです。またシャドーAI対策を進めていなかったことも想定されますね。セキュリティ対策をせずに、ローカルファイルにアクセスできるAIツールを導入するのはNGです！ — まな(@ADHDHSP249834)

MCC乗っ取りの推定原因

@hassii_ad 氏は乗っ取りの原因として4つの可能性を挙げています。

原因	概要
悪意あるWebサイト指示	プロンプトインジェクションによりAIの動作を乗っ取る
配布プロンプトへの悪意ある指示混入	AIコンサルまたは社員が使用したプロンプトに仕込まれた攻撃
MCPツールの悪用	Model Context Protocol ツールを経由した不正操作
トークン流出	自動化過程でAPIトークンや認証情報が漏洩

特に深刻なのは、MCCが正規の権限で操作された場合、通常の操作と区別がつかず「補償は絶望的」という点です。Google Ads の MCC アカウントは複数の広告アカウントを一元管理する仕組みのため、一度乗っ取られると被害が連鎖的に広がります。

Google Ads のセーフガードはなぜ機能しなかったのか

Google Ads には予算制限やセキュリティ機能が存在しますが、正規権限で操作された場合にはほとんど機能しません。

既存のセーフガード一覧

機能	内容	乗っ取り時に有効か
日予算の上限	1日の費用は日予算の2倍まで	攻撃者が日予算自体を変更可能
月間費用上限	月間費用は日予算 x 30.4 まで	同上
アカウント予算	アカウント全体の費用上限を設定可能。上限到達で全広告停止	攻撃者が上限を変更・解除可能
異常な予算変更の確認	大幅な予算変更時（例: $100→$1,000）に確認ダイアログ表示	UI操作のみ。API経由なら確認なし
不審なアクティビティの検知	Google が異常を検知すると一時的な日次支出制限を適用	「正規権限」の操作は異常と判定されにくい
自動ルール	一定額到達でキャンペーンを一時停止するルール設定が可能	攻撃者がルール自体を削除可能

セーフガードが無力化される理由

今回の事件の核心は、攻撃者が MCC の正規の管理者権限を取得している点です。

Backlog 問い合わせ課題を Claude で自動分析してコメント投稿する構成（Webhook + Lambda + Bedrock）

Mon, 02 Mar 2026 00:00:00 +0000

Backlog 問い合わせ課題を Claude で自動分析してコメント投稿する構成

Backlog を問い合わせ管理に使っていると、課題が登録されるたびに内容を確認し、分類や初期対応を行う作業が発生します。この作業を Claude に任せ、課題が追加された瞬間に自動で分析コメントを投稿する仕組みを構築します。

全体構成

┌──────────┐ Webhook ┌─────────────┐ invoke ┌──────────┐
│ Backlog │ ──── JSON ────→ │ API Gateway │ ────────────→ │ Lambda │
│ (課題追加) │ │ │ │ (受信) │
└──────────┘ └─────────────┘ └────┬─────┘
│
SQS enqueue
│
▼
┌──────────┐ コメント投稿 ┌─────────────┐ Claude API ┌──────────┐
│ Backlog │ ◀── POST ────── │ Lambda │ ◀──────────── │ Amazon │
│ (課題) │ │ (処理) │ │ Bedrock │
└──────────┘ └─────────────┘ └──────────┘

なぜ 2 段構成（Lambda + SQS）なのか

Backlog の Webhook は 10 秒以内に HTTP 200 を返さないとタイムアウトし、失敗として再送を繰り返します。Claude の分析には数十秒かかるため、受信 Lambda は即座に 200 を返し、SQS を介して処理 Lambda に非同期で委譲します。

Claude Ads で広告運用を186項目自動監査 --- Claude Code スキルが広告代理店の仕事を奪い始めた

Mon, 02 Mar 2026 00:00:00 +0000

Claude Ads で広告運用を186項目自動監査 — Claude Code スキルが広告代理店の仕事を奪い始めた

@ratekomaru 氏が X で紹介した「Claude Ads」が話題になっています。

Claudeやばすぎだろwwww ピンポイントで業界潰して回ってる。無料でGoogle・Meta・YouTube・LinkedIn・TikTok・Microsoft Adsなど186項目にわたるチェック機能を備えたClaude Code向けの包括的な有料広告監査・最適化スキル「Claude Ads」

12 万超のインプレッション、1,700 以上のいいねという反響は、「AI が広告運用の専門職を代替する」という予感を多くの人が共有している証拠でしょう。本記事では Claude Ads の仕組みを掘り下げつつ、広告業界に起きている構造変化を整理します。

Claude Ads とは何か

Claude Ads は、Claude Code 向けに作られたオープンソースの広告監査・最適化スキルです。MIT ライセンスで公開されており、インストールは1コマンドで完了します。

1

curl -fsSL https://raw.githubusercontent.com/AgriciDaniel/claude-ads/main/install.sh | bash

主な特徴は以下の通りです。

項目	内容
対応プラットフォーム	Google Ads, Meta Ads, YouTube Ads, LinkedIn Ads, TikTok Ads, Microsoft Ads
チェック項目数	190（Google 74, Meta 46, LinkedIn 25, TikTok 25, Microsoft 20）
業種テンプレート	SaaS, EC, ローカルサービス, B2B, モバイルアプリ, 不動産, ヘルスケア, 金融など 11 種
並列実行	6 つのサブエージェントが同時にプラットフォーム別監査を実行
ライセンス	MIT

アーキテクチャ — サブエージェント並列実行

Claude Ads の設計はシンプルですが効果的です。

Claude Code から Nano Banana 2 を呼ぶ — クロスモデル Skills 活用術

Mon, 02 Mar 2026 00:00:00 +0000

Claude Code から Nano Banana 2 を呼ぶ — クロスモデル Skills 活用術

鹿野壮さん（@tonkotsuboy_com）が、Claude Code から Gemini の画像生成モデル「Nano Banana 2」を直接呼び出せるスキルを紹介しています。

Nano banana 2をClaude Codeから呼び出せるスキルを見つけた、すごくいい Nano bananaのためだけに毎回Geminiアプリを立ち上げる手間が省ける。画像参照とか複雑な命令をしたり、複数枚同時に作れるの便利すぎるブヒィ

— 鹿野壮 (@tonkotsuboy_com)

投稿にはいいね 232、ブックマーク 301 と反響が大きく、「AI コーディングツールから別の AI モデルを呼ぶ」というクロスモデル連携への関心の高さがうかがえます。

Nano Banana 2 とは何か

Nano Banana 2 は、Google DeepMind が 2026 年 2 月 26 日に発表した画像生成モデルです。正式な技術名称は Gemini 3.1 Flash Image で、「Nano Banana」は Gemini のネイティブ画像生成機能のブランド名として使われています。

Nano Banana ファミリーには 3 つのモデルがあります。

モデル	技術名	特徴
Nano Banana 2	Gemini 3.1 Flash Image	高速・高コスパ。Flash ベースで大量生成向き
Nano Banana Pro	Gemini 3 Pro Image	最高品質。プロフェッショナル制作向け
Nano Banana	Gemini 2.5 Flash Image	初代。低遅延タスク向け

Nano Banana 2 の主な機能は以下の通りです。

Claude Code スキルで AI ワークフローを自動化する — Ralph Loop + YAML 宣言的定義の実践

Mon, 02 Mar 2026 00:00:00 +0000

Claude Code スキルで AI ワークフローを自動化する — Ralph Loop + YAML 宣言的定義の実践

kenfdev さん（@kenfdev）が、Claude Code のスキル機能を活用した AI エージェントのワークフロー自動化について、実践的な技術記事を公開しています。

Claude Code のスキルを中心に、AIエージェントのワークフローを自動化してみた話を書きました。 bash の while ループで claude -p を繰り返す Ralph Loop と、YAML でワークフロー定義を組み合わせて、plan → implement → review → finalize を自律的に回す仕組みです。 TAKTほどの精度には及ばないのですが、それなりに自分のワークフローでは活用できています。

— kenfdev (@kenfdev)

記事の核は「Ralph Loop」と「YAML ワークフロー定義」という 2 つの技術を Claude Code スキルで統合し、plan → implement → review → finalize を自律的に回す仕組みです。

Ralph Loop とは何か

起源

Ralph Loop（正式には Ralph Wiggum Loop）は、Geoffrey Huntley が考案した AI 開発自動化パターンです。名前はシンプソンズのキャラクターに由来しますが、仕組み自体は極めてシンプルです。

基本構造

1
2
3
4
5
6
7


while true; do
 result=$(claude -p "プロンプト")
 # 完了判定
 if [[ "$result" == *"COMPLETE"* ]]; then
 break
 fi
done

bash の while ループで claude -p（ヘッドレスモード）を繰り返し呼び出す、たったこれだけです。-p フラグは Claude Code を非対話モードで実行し、結果を標準出力に返します。

Claude Code スキルで「穴場市場」を自動発掘 — コードを書かない AI エージェント活用術

Mon, 02 Mar 2026 00:00:00 +0000

Claude Code スキルで「穴場市場」を自動発掘 — コードを書かない AI エージェント活用術

「Claude Code はプログラミング支援ツール」——そう思い込んでいませんか？

@koder_dev さんのポストで紹介された Zenn 記事（s4kura 氏）が話題になっています。Claude Code の スキル機能 を使って「穴場市場を探させる」という、コーディングとは全く異なる使い方です。

「Claude Code にスキル自作させて穴場市場探させるって Zenn の記事めっちゃ面白かった。いや本当自分の周りも自作 skill でプログラミング作って色んな作業やらせてる、無限に応用効くからなー」— @koder_dev

Claude Code スキルとは何か

基本概念

Claude Code のスキルは、SKILL.md ファイルに指示を記述することで Claude の機能を拡張する仕組みです。いわば 「プロンプトエンジニアリングのパッケージ化」 です。

スキルなし:
毎回 → 「こういう手順で」「こういう基準で」「こういう形式で」と指示
結果 → 指示漏れ、品質のばらつき
スキルあり:
毎回 → /skill-name と入力するだけ
結果 → 事前定義した手順・基準・形式が自動適用

スキルの構造

スキルは SKILL.md を中心としたディレクトリです。

my-skill/
├── SKILL.md # メイン指示（必須）
├── references/ # 判断基準・リファレンス（任意）
├── templates/ # テンプレート（任意）
├── scripts/ # 実行スクリプト（任意）
└── examples/ # サンプル出力（任意）

SKILL.md は YAML フロントマターとマークダウンコンテンツの 2 部構成です。

Claude Code スキルの自動最適化 — テキスト勾配で「職人芸プロンプト」を工学に変える

Mon, 02 Mar 2026 00:00:00 +0000

Claude Code スキルの自動最適化 — テキスト勾配で「職人芸プロンプト」を工学に変える

「プロンプトは職人芸」——そんな時代が終わりつつあります。

@yusuke_post さんが発表した X 記事では、プロンプトエンジニアリングを自動化する研究を応用して Claude Code の Skills を自動最適化する手法が紹介されています。ヒアリングメモから SaaS 導入提案書を生成するスキルを題材に、4 イテレーションで 13.6 点のスコア改善を達成しました。

@kgsi さんも「この取り組みすごい、ナレッジが溜まっている企業や組織ほどこの仕組みで効果が出そう」と反応しています。

全体像：何がどう繋がっているのか

この記事で扱う内容を先に俯瞰します。

課題

Claude Code の Skills（SKILL.md）は、タスクの手順を定義する「指示書」です。しかし、良い指示書を書くのは難しく、試行錯誤が属人的になりがちです。

graph LR
A["人間が SKILL.md を書く"] --> B["実行"]
B --> C["結果がイマイチ"]
C --> D["🤔 勘で修正<br/>（= 職人芸）"]
D --> B
style D fill:#f9c74f,color:#000

解決策：テキスト勾配による自動改善ループ

深層学習がパラメータを自動で最適化するように、SKILL.md を自動で最適化するのがテキスト勾配です。

graph TD
A["① SKILL.md（現在の指示書）で実行"] --> B["② 出力を正解データと比較<br/>（人間の過去の成果物）"]
B --> C["③ AI が差分を分析し改善点を言語化<br/>= テキスト勾配"]
C --> D["④ テキスト勾配に従って<br/>SKILL.md を改訂"]
D --> E["⑤ 改訂版で再実行"]
E --> B
C -.- F["例: 優先度の整理ステップが欠如している"]
style C fill:#4ecdc4,color:#000
style F fill:#f0f0f0,color:#555,stroke-dasharray: 5 5

4 回繰り返すだけで 13.6 点のスコア改善を達成。

Claude Code の /simplify と /batch — AIコーディングは「書く」から「整える・並列で移す」へ

Mon, 02 Mar 2026 00:00:00 +0000

Claude Code の /simplify と /batch — AI コーディングは「書く」から「整える・並列で移す」へ

Tsukasansan 氏のポストが、Claude Code v2.1.63 で追加された 2 つの新スキル /simplify と /batch を紹介しています。この 2 つのスキルは、AI の役割を「コードを書く補助ツール」から「品質を整え、大規模な変更を並列実行する分業チーム」へと変える転換点です。

/simplify — PRに出す前の「仕上げ」を自動化

/batch — 大規模マイグレーションを並列で一気に実行

Claude Code の開発者 Boris Cherny 氏も、この 2 つのスキルについて「毎日使っている」と述べています。

/simplify: 3 つのエージェントによる自動コードレビュー

/simplify は、実装完了後に実行する「仕上げ」コマンドです。git diff で最近の変更を検出し、3 つの専門レビューエージェントを並列実行します。

3 つのレビュー観点

エージェント	検出対象	具体例
コード再利用	重複ロジック、既存ユーティリティで置き換え可能なコード	同じバリデーションが 3 箇所にコピペされている
コード品質	冗長な状態管理、パラメータの肥大化、リーク抽象化	引数が 8 個ある関数、使われていない変数
効率性	不要な処理、並列化の機会、ホットパス内の重い処理	ループ内での毎回の DB クエリ、不要な再レンダリング

3 つのエージェントが問題を検出するだけでなく、修正まで自動的に適用します。従来のリンターと異なり、高レベルのアーキテクチャ上の問題に対応するのが特徴です。

使い方

1
2
3
4
5
6
7


# 基本: 変更ファイルを自動レビュー・修正
/simplify

# 特定の観点にフォーカス
/simplify focus on memory efficiency
/simplify check for unnecessary dependencies
/simplify focus on security patterns in the auth flow

実践的なワークフロー

実装完了後、PR を出す前に /simplify を実行するだけです。

Claude Code の「処理」と「ドメイン知識」をレイヤー分離する設計術

Mon, 02 Mar 2026 00:00:00 +0000

Claude Code の「処理」と「ドメイン知識」をレイヤー分離する設計術 — スキルが複利で効く構造をつくる

gura 氏の投稿が、Claude Code を使った PM 業務の知見を共有しています。2 ヶ月間の実運用で最も効いた設計判断は、Skill（処理レイヤー）と CLAUDE.md（ドメイン知識レイヤー）の分離だったとのことです。この考え方は、Claude Code の公式アーキテクチャとも一致する設計パターンです。

問題：なぜ全部入りの設定は破綻するのか

Claude Code を使い始めると、多くの人が CLAUDE.md にあらゆる情報を詰め込みます。プロジェクトの規約、処理手順、ドメイン知識、スタイルガイド。しかしこの「全部入り」アプローチには構造的な問題があります。

コンテキスト汚染: CLAUDE.md はセッション開始時に全文がロードされるため、情報量が増えるほどトークンを圧迫します
Lost in the Middle: 長大なコンテキストの中間部分が軽視される現象が発生します
再利用不能: プロジェクト固有の知識と汎用的な処理手順が混在し、別プロジェクトへの横展開ができません

SO Technologies 開発者ブログの分析によると、全部入り CLAUDE.md はセッション開始時にコンテキストの 40〜50% を占有するケースもあったと報告されています。

2 つのレイヤーを分離する

gura 氏が提唱するのは、明確な 2 層構造です。

Skill = 処理レイヤー

「どのフォルダから何を読んで、どう加工して、どこに出すか」を定義する

Skill は入力と出力が明確な、小さな処理単位です。

Skill の例	入力	出力
議事録の文字起こし	音声データ	テキスト議事録
外部向け議事録変換	内部議事録	フィルタリング済み議事録
Slack 共有	文書	Slack メッセージ
レポート生成	各種データ	フォーマット済みレポート

Skill は どのプロジェクトでも処理の骨格は同じ です。ファイルの場所は .claude/skills/<skill-name>/SKILL.md に配置し、YAML フロントマターで名前と説明を記述します。

Claude Code ベストプラクティス — 成果を安定させる 7 つの鉄則と公式ガイドの設計思想

Mon, 02 Mar 2026 00:00:00 +0000

Claude Code ベストプラクティス — 成果を安定させる 7 つの鉄則と公式ガイドの設計思想

qiitapoi 氏のポストが、Qiita 記事「Claude Code ベストプラクティス – 成果を安定させる 7 つの鉄則」を紹介しています。この記事は、Claude Code の公式ベストプラクティスを実務者の視点で 7 つのルールに凝縮したもので、「具体的に頼む」「必ず検証する」という基本から、セッション管理やコスト意識まで、日々の運用に直結する指針をまとめています。

本記事では、この 7 つの鉄則を公式ドキュメントの設計思想と照らし合わせながら、なぜそのルールが効くのかを掘り下げます。

公式ベストプラクティスの根本原則: コンテキストウィンドウ

Claude Code 公式ベストプラクティスは、冒頭で明確に述べています。

ほとんどのベストプラクティスは 1 つの制約に基づいています。Claude のコンテキストウィンドウはすぐにいっぱいになり、満杯になるにつれてパフォーマンスが低下します。

Claude Code の 200K トークンのコンテキストウィンドウには、すべてのメッセージ、読み取ったファイル、コマンド出力が蓄積されます。コンテキストが埋まるにつれて、初期の指示を「忘れる」、ミスが増えるといった品質低下が起きます。7 つの鉄則のほぼすべてが、この制約への対処法として理解できます。

7 つの鉄則と公式ガイドの対応

nogataka 氏の Qiita 記事が提案する 7 つの鉄則を、公式ドキュメントの推奨事項と対応させて整理します。

鉄則	内容	公式ガイドの対応セクション
1. 具体的に頼む	5W1H で指示を明確にする	プロンプトで具体的なコンテキストを提供する
2. 必ず検証する	diff、テスト、コストの 3 点確認	Claude に自分の作業を検証する方法を与える
3. CLAUDE.md でルール言語化	プロジェクト固有の規約を明文化する	効果的な CLAUDE.md を書く
4. セッション短く保つ	1 タスク 1 セッション	セッションを管理する
5. 計画→実行の 2 段階	5 分ルールで判断	最初に探索し、次に計画し、その後コーディングする
6. コスト意識	/cost で定期確認	コンテキストを積極的に管理する
7. 自動化への次ステップ	Hooks, MCP, Agent Teams	自動化とスケール

7 つの鉄則は、公式ガイドの膨大な内容を実務者が日常的に参照できる形に圧縮したものと位置づけられます。

Claude Code 時代の .env 管理 — 「平文で置かない」秘密情報の新しい守り方

Mon, 02 Mar 2026 00:00:00 +0000

Claude Code 時代の .env 管理 — 「平文で置かない」秘密情報の新しい守り方

@yousukezan 氏のポストが、AI 駆動開発における秘密情報管理の盲点を端的に指摘しています。

Claudeが社内に広がるほど、.envが危ない。Cowork時代に必要なのは「便利さ」より秘密情報の置き場所

引用元の Qiita 記事では、Claude Code や Cowork が「チャットで質問するだけのツール」から「ローカルファイルに直接アクセスする開発エージェント」へ進化したことで、従来の .gitignore だけでは守りきれない脅威が生まれていると論じています。本記事では、この問題の技術的背景と実践的な対策を掘り下げます。

何が変わったのか — 脅威モデルの転換

従来の開発ワークフローでは、.env ファイルの脅威モデルは明確でした。

脅威	対策
Git リポジトリへの混入	`.gitignore` に記載
本番環境への漏洩	環境変数やシークレットマネージャで注入
他人のマシンへの流出	ローカルに置く前提なので問題なし

ところが、Claude Code のような AI エージェントがローカルファイルを直接読み書きする時代になると、第三の脅威が加わります。

新しい脅威	内容
AI エージェントによる読み取り	`.env` がツールの入力コンテキストに載る
意図しないクラウド送信	読み取った内容が LLM の API リクエストに含まれる
組織内の横展開	Cowork で複数人が同じプロジェクトを触る際の露出

IPA「情報セキュリティ 10 大脅威 2026」でも「AI の利用をめぐるサイバーリスク」が初選出で 3 位にランクインしており、この脅威モデルの転換は業界全体の認識となりつつあります。

Claude Code は .env をどう扱うのか

自動読み込み問題

セキュリティ研究者 Dor Munis 氏の調査によると、Claude Code は .env、.env.local などのファイルを自動的に読み込み、API キーやトークンをメモリに展開していることが判明しています。プロキシ認証情報が意図せず読み込まれ、HTTP 407 エラーとプロキシ料金の異常な高騰として問題が顕在化しました。

Claude Cowork 入門ガイド — プロンプトを頑張る時代の終わり、「仕組み化」で AI と働く新しいスタイル

Mon, 02 Mar 2026 00:00:00 +0000

Claude Cowork 入門ガイド — プロンプトを頑張る時代の終わり、「仕組み化」で AI と働く新しいスタイル

長谷川氏（@taichi_we）が投稿した「Claude Cowork の始め方ガイド」が X 上で大きな反響を呼んでいます。ブックマーク数 14,850、いいね 6,021、閲覧数 300 万超という驚異的な数字です。

プロンプトを頑張る時代は、もう終わりに近い。これから必要なのは、「AIに何を渡せば仕事が進むか」を整えることです。

この記事では、元ポストの内容をベースに、公式ドキュメントや技術解説記事の情報を加えて、Claude Cowork の全体像と実践的な始め方を解説します。

Claude Cowork とは何か

Claude Cowork は、Anthropic が提供する 非エンジニア向けの自律型 AI エージェント機能 です。Claude Desktop アプリに統合されており、「Chat」「Code」と並んで「Cowork」タブから利用できます。

もともと Claude Code はエンジニア向けのコマンドラインツールとして提供されていましたが、ファイル整理やスプレッドシート作成など、コーディング以外の用途にも多く使われていることに Anthropic が気づきました。実際、Claude Code でも業務タスクは十分に実行できます。ただし、ターミナル操作は非エンジニアにとってハードルが高いという課題がありました。Cowork は Claude Code と同等の能力を GUI で包み、誰でもアクセスできるようにしたものです。

項目	Claude Chat	Claude Code	Claude Cowork
対象ユーザー	全般	開発者中心（だが業務タスクも可能）	非エンジニアを含む全職種
インターフェース	Web / アプリ	ターミナル（CLI）	Desktop アプリ（GUI）
ファイル操作	アップロード / ダウンロード	ローカル直接アクセス	ローカル直接アクセス
自律実行	なし	あり	あり
差別化ポイント	手軽な対話	Bash 実行、Git 操作、MCP、スキル	プラグイン、コネクター、スケジュール実行
前提スキル	不要	ターミナル操作に慣れている必要あり	不要

本質的な違いは「何ができるか」ではなく「誰がアクセスしやすいか」です。Claude Code でもレポート作成やファイル整理といった業務タスクは問題なくこなせます。Cowork はその能力を、ターミナルに馴染みのないユーザーにも開放したものと考えるのが正確です。

Claude Opus 4.6 がゼロデイ脆弱性を500件発見 — AI推論がセキュリティ業界を揺るがす

Mon, 02 Mar 2026 00:00:00 +0000

Claude Opus 4.6 がゼロデイ脆弱性を500件発見 — AI推論がセキュリティ業界を揺るがす

@neurostack_0001 氏のポストが、Anthropic の衝撃的な発表を紹介しています。Claude Opus 4.6 が、ファジングやカスタムツールを使わず、コードの推論だけで500件以上のゼロデイ脆弱性を発見したという内容です。

AnthropicがClaude Opus 4.6で「ゼロデイ脆弱性を大規模に発見できる」と発表。500件以上の高重大度脆弱性を検出・検証済み。ファジングやカスタムツール不要で、コードの推論だけで脆弱性を見つけている点が注目。

この発表は、CrowdStrike や Cloudflare の株価を8%以上下落させるほどのインパクトを持ちました。セキュリティ業界に何が起きているのか、技術的な背景から掘り下げます。

ファジングとは何か

ファジング（Fuzzing）は、プログラムに対して無効なデータ、予期しないデータ、ランダムなデータを大量に入力し、クラッシュや異常動作を引き起こすことで脆弱性を検出するテスト手法です。1988年にウィスコンシン大学の Barton Miller 教授が考案し、現在ではセキュリティテストの標準手法となっています。

ファジングの種類

ファジングは、テスト対象の内部構造をどの程度把握しているかによって3つに分類されます。

分類	内部構造の把握	特徴
ブラックボックス	なし	入出力のみを観察。実装が不明でも実行可能
グレーボックス	部分的	コードカバレッジを計測し、入力生成を最適化
ホワイトボックス	完全	ソースコードを解析し、制約条件を満たす入力を生成

また、入力データの生成方法でも分類できます。

ミューテーションファジング: 既知の有効な入力（シード）に対して、ビット反転やバイトの挿入・削除・置換などの変異を加えてテストケースを生成します。実装が容易で汎用性が高い手法です
ジェネレーションファジング: 入力データの構造や文法を定義し、仕様に基づいて有効な形式でありながらも不正な値を含むテストケースを生成します。プロトコルやファイルフォーマットのテストに有効です

カバレッジガイドファジング — AFL の登場

2014年に登場した AFL（American Fuzzy Lop）は、ファジングの実用性を大きく向上させました。名前はウサギの品種に由来しています。

AFL の革新は「カバレッジガイド」の概念です。テスト対象プログラムをインストルメント（計測コードの埋め込み）し、各入力がどの実行経路を通ったかを記録します。新しい経路を発見した入力を優先的にミューテーションすることで、コードの未探索領域へ効率的に到達します。

[シード入力] → [ミューテーション] → [実行・カバレッジ計測]
↑ ↓
└── [新しい経路を発見？] ──┘
Yes → キューに追加
No → 破棄

この手法はグレーボックスファジングとも呼ばれ、AFL の後継である AFL++ や Google の libFuzzer など、多くのツールが同様のアプローチを採用しています。

NotebookLM に「40 人の天才の思考」をストックする — AI を多角的な思考パートナーに変える方法

Mon, 02 Mar 2026 00:00:00 +0000

NotebookLM に「40 人の天才の思考」をストックする — AI を多角的な思考パートナーに変える方法

「AI に自分の浅い考えしか入力できなくて、薄い回答しか返ってこない」

この問題に対する解決策が SNS で話題になっています。@ai_jitan さんが提案する手法は、孫子、アドラー、ドラッカーなど 40 人の天才の思考法を NotebookLM にストックし、AI を「多角的な思考パートナー」に変えるというものです。

@karasu_ai さんも「40 人の天才の思考をプロンプトとしてストックするって発想がすごい」と反応し、大きな反響を呼びました。

コア・アイデア：入力の質がAI出力の質を決める

問題：「自分の浅い考え」がボトルネック

AI に質問するとき、多くの人は自分の知識の範囲内で入力を行います。

ユーザー: 「売上を伸ばすにはどうすればいい？」
AI: 「マーケティングを強化しましょう。SNS広告や...」

汎用的で薄い回答しか返ってきません。入力が浅ければ、出力も浅いのです。

解決策：天才の思考フレームワークを注入する

同じ質問でも、複数の偉人の思考法をコンテキストとして与えると：

孫子（戦略家）: 「敵（競合）を知り己を知れば百戦危うからず。
まず市場と競合の徹底分析から始めよ」
ドラッカー（経営学者）: 「顧客は何に価値を見出しているか？
それを問うことが出発点」
アドラー（心理学者）: 「顧客の劣等感や承認欲求に着目せよ。
人は理想の自分に近づくために消費する」

1 つの課題に対して、戦略・経営・心理という 3 つの異なる角度からアプローチが得られます。これが「多角的な視点での課題解決」の正体です。

NotebookLM を使う理由

NotebookLM の特性

Google が提供する NotebookLM は、アップロードした資料（ソース）をもとに回答を生成する AI ツールです。通常の ChatGPT や Claude との決定的な違いは：

ソースに基づいた回答: 学習データ全体ではなく、アップロードした資料に基づいて回答する
引用の透明性: 回答の根拠となるソースを明示する
ペルソナカスタマイズ: AI の役割や視点を詳細に設定できる（最大 10,000 文字）

なぜ「ストック」が重要か

ChatGPT に「孫子になりきって答えて」と毎回指示するのと、NotebookLM に孫子の著作や思考法をソースとしてアップロードしておくのでは、回答の深さが根本的に異なります。

OpenClaw で 13 体の AI チームを組織する — 低スペック PC で営業・SNS 運用を完全自動化

Mon, 02 Mar 2026 00:00:00 +0000

OpenClaw で 13 体の AI チームを組織する — 低スペック PC で営業・SNS 運用を完全自動化

@gagarotai200（ガガロットAI）さんのポストが話題になっています。OpenClaw を使って 13 体の AI エージェントを組織し、営業・SNS 運用・分析・アポ取りまで完全自動化しているリアルな環境を公開した内容です。16 万回以上の閲覧、880 件のブックマークを集めており、実運用例の少ない OpenClaw 界隈で注目を集めました。

『Open Claw』って実際の環境を出してる人マジで少ないのでオラの13体のAI組織で「営業」「SNS運用」「分析」「アポ取り」など完全自動で行わせてる実際のリアルな環境を3日間限定で全て公開した。

OpenClaw とは何か

OpenClaw は、PSPDFKit の創業者 Peter Steinberger 氏が 2025 年 11 月に公開したオープンソースの AI エージェントフレームワークです。GitHub スター数は 20 万超に達し、2026 年現在で最も注目されている AI エージェント基盤の一つです。

従来のチャットボットとの最大の違いは、質問に答えるだけでなく、タスクを直接実行できる点にあります。ファイル操作、メール送信、スケジュール管理、コード実行など、PC 上でユーザーが行う作業を AI が代行します。

主な特徴

特徴	内容
動作環境	ローカルマシン（Mac, Linux, Windows WSL2）
通信チャネル	Discord, Telegram, Slack, WhatsApp, Signal, iMessage
スキルシステム	ClawHub（3,000+ のコミュニティスキル）
エージェント定義	SOUL.md（自然言語でのパーソナリティ定義）
マルチエージェント	Multi-Agent Routing でエージェント間を分離
コスト	オープンソース（API 従量課金のみ）

13 体 AI チームの構成

ガガロットさんの環境では、MacBook Pro M1 上で 13 体の AI エージェントを階層的に組織しています。

Prompt Request — Pull Requestの次の形：コードを書く時代から「意図を書く時代」へ

Mon, 02 Mar 2026 00:00:00 +0000

Prompt Request — Pull Request の次の形：コードを書く時代から「意図を書く時代」へ

@The_AGI_WAY（ハヤシシュンスケ）氏のポストが話題です。

コードを書く時代から、意図を書く時代へ。GitHub Issue にこう書く。「[auto] ユーザー認証のエラーハンドリングを追加しろ」

引用元は @Shuns_AI 氏が X で公開した長文記事「Prompt Request — Pull Request の次の形」です。AI エージェントが GitHub Issue を読み取り、ブランチ作成から実装・テスト・PR 作成・マージまでを自律的に完了するワークフローを提案しています。92 タスクで 95% の成功率を達成したという実績とともに、「良い Issue を書く能力」こそが開発者の最重要スキルになるという主張が注目を集めました。

「Prompt Request」とは何か

「Prompt Request」は、従来の Pull Request（PR）に代わる新しい開発パラダイムを表す概念です。

項目	Pull Request	Prompt Request
開発者の作業	コードを書いて PR を作成する	GitHub Issue に意図を書く
実装の担い手	人間の開発者	AI エージェント
レビュー	人間がコードレビュー	AI がピアレビュー + 人間が最終確認
マージ	人間が判断してマージ	条件を満たせば自動マージ
所要時間	数時間〜数日	5〜15 分

PR がコードの差分を中心とした「成果物の提出」であるのに対し、Prompt Request は「意図の伝達」が起点になります。開発者が書くのはコードではなく、何をしたいかという自然言語の指示です。

ワークフローの全体像

記事で提案されているワークフローは次のとおりです。

SaaS の終焉（SaaSpocalypse）--- 自律エージェントが Seat 課金を破壊し、ソフトウェア業界を再編する

Mon, 02 Mar 2026 00:00:00 +0000

SaaS の終焉（SaaSpocalypse）— 自律エージェントが Seat 課金を破壊し、ソフトウェア業界を再編する

@shoji_hq 氏が X で共有した、Insight Partners 共同創業者による「SaaS の終焉（Apocalypse）」Podcast の備忘メモが注目を集めています。

AIの津波はまだこれから。本丸は「Autonomous Agents（自律エージェント）」であり、これが今からやってくる。これが浜にぶつかった瞬間、大きな津波になる。

この警告は予言ではなく、すでに現実になりつつあります。2026 年 2 月、ソフトウェアセクターは「SaaSpocalypse」と呼ばれる大暴落を経験し、1 兆ドル超の時価総額が消失しました。本記事では、何が起きているのかを構造的に整理します。

Insight Partners が語った 5 つの構造変化

@shoji_hq 氏のメモは、Podcast の要点を 5 つに整理しています。それぞれを掘り下げます。

1. 自律エージェントが本丸

自律的にタスクを分解し、ツールを選び、実行し、報告する存在。これが世の中の構造を変える。

Insight Partners 自身も「million-Agent problems」という表現を使っています。協調する複数のエージェントが、一晩かけて自律的に作業を完了し、翌朝には成果物が揃っている世界です。Deloitte の予測では、自律型 AI エージェント市場は 2026 年に 85 億ドル、2030 年に 350 億ドルに達するとされています。

重要なのは、これが単なるチャットボットの延長ではない点です。CUA（Computer-Using Agent）は複雑なソフトウェアインターフェースを人間より上手に操作できるレベルに達しており、「デジタル従業員」として機能し始めています。

2. API の応答速度が UI より重要になる

人間は400msで遅延を感じる。エージェントは80msを最適化する。美しいUIより、APIの応答速度が大切。

エージェントが主要なユーザーになると、設計のプライオリティが逆転します。

指標	人間向け設計	エージェント向け設計
遅延の閾値	400ms	80ms
重視する点	UI/UX の美しさ	API のレスポンス速度
インターフェース	グラフィカル	プログラマティック
同時接続	数百〜数千	数万〜数百万
稼働時間	営業時間	24 時間 365 日

Insight Partners の Ryan Hinkle 氏は「ナレッジワーカーが仕事に不可欠とするシステムは AI の大きな恩恵を受ける。ただのファイリングキャビネットは脅威にさらされる」と述べています。

Second Me — AI に「自分の分身」を持つ時代と OpenClaw との本質的な違い

Mon, 02 Mar 2026 00:00:00 +0000

Second Me — AI に「自分の分身」を持つ時代と OpenClaw との本質的な違い

前回の記事で OpenClaw による 13 体 AI チーム構築を紹介しました。OpenClaw では SOUL.md というファイルでエージェントの「人格」を定義しますが、これは本当に「自分の分身」と呼べるのでしょうか。Second Me というプロジェクトは、まったく異なるアプローチで「AI による自分の分身」を実現しようとしています。

SOUL.md の限界 — 「指示書」は「分身」ではない

OpenClaw の SOUL.md は Markdown で書かれた設定ファイルです。エージェントの名前、性格、役割、制約を自然言語で記述します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


---
name: sales-agent
model: claude-sonnet-4-6
---

あなたは営業チームの一員です。丁寧に話してください。

## 役割
- リード情報の整理と優先順位付け
- 提案メールの下書き作成

これは強力な仕組みですが、あくまで外から与える指示書です。「営業エージェントをこう振る舞わせたい」という設計者の意図を反映したものであり、「この人ならどう考えるか」を再現するものではありません。

ハーネスエンジニアリング入門 — AIエージェントの性能はモデルではなく周辺設計で決まる

Mon, 02 Mar 2026 00:00:00 +0000

ハーネスエンジニアリング入門 — AIエージェントの性能はモデルではなく「周辺設計」で決まる

朱雀氏のポストが、Claude Code や Codex の仕組みを理解するうえで「ハーネス」の概念が重要だと紹介しています。2026 年に入り、AI エージェント開発の焦点は「どのモデルを使うか」から「モデルの周囲をどう設計するか」に移りました。この周辺設計を指す言葉がハーネスエンジニアリングです。

Claude CodeやCodexの仕組みを詳しく理解したい人にはこれがおすすめ。「ハーネス」について詳しく解説してくれている。

ハーネスとは何か

ハーネスとは、AI モデルを囲む運用インフラのことです。Phil Schmid 氏の解説では、コンピュータに例えて次のように整理しています。

コンピュータ	エージェント
CPU	モデル（推論エンジン）
RAM	コンテキストウィンドウ（作業メモリ）
OS	ハーネス（コンテキスト管理、ツール処理、起動シーケンス）
アプリケーション	エージェント（ユーザー固有のロジック）

モデルが CPU なら、ハーネスは OS です。どれだけ高性能な CPU を積んでも、OS が貧弱では実用的なアプリケーションは動きません。

具体的には、ハーネスは以下の要素を管理します。

会話・コンテキスト管理: セッション間の記憶、コンテキストウィンドウの最適化
ツール呼び出し層: MCP/SDK ツールの提供と制御
権限管理: 実行可能な操作の制御
セッション・ファイルシステム状態: 作業ディレクトリ、Git 状態の管理
ループ制御・エラーハンドリング: リトライ、ガードレール、検証
観測性: ログ、メトリクス、テレメトリ

モデルではなくハーネスが性能を決める

2026 年に入ってから、ハーネスの重要性を示す数値データが相次いで公開されています。

ハーネス変更だけで性能が 10 倍に

ベンチマーク結果によると、ツール形式を変えただけで 15 モデルすべてのスコアが改善しました。最も劇的だったのは Grok Code Fast 1 で、6.7% から 68.3% に跳ね上がり約 10 倍でした。モデルの重みには一切手を加えていません。

同じモデルでもスキャフォールドで倍近い差

Claude Opus 4.5 は、あるスキャフォールドで 42%、別のスキャフォールドで 78% を達成しました。同じモデルでも、ハーネスの設計次第で性能が倍近く変わります。

オープンソース AI は「無料」でも「民主化」でもない --- 重みの公開と推論コストの間にある物理法則の壁

Mon, 02 Mar 2026 00:00:00 +0000

オープンソース AI は「無料」でも「民主化」でもない — 重みの公開と推論コストの間にある物理法則の壁

@kubotamas 氏が X で共有した、Anthropic CEO Dario Amodei の発言が議論を呼んでいます。

AIのオープンソース化は無料でも民主化でもない。モデルの重みをダウンロードすることは出来ても、実際に推論するのにコストがかかる。AIは従来のオープンソースとは本質的に異なる。重みを手に入れても計算資源がなければ、解釈・改変することはできない。オープン化という約束は物理法則の壁で制限されている

この投稿は、@r0ck3t23 氏（Dustin）のツイートを引用しています。Dustin 氏は Amodei の動画インタビューから「オープンソース AI は無料ではなかった。一度もそうだったことはない」とまとめ、1,200 以上のいいねを集めました。

本記事では、この「オープンソース AI の幻想」の構造を掘り下げます。

Amodei の主張 — 「これは Linux ではない」

Dario Amodei はインタビューの中で明確に述べています。

“It’s not free. You have to run it on inference and someone has to make it fast on inference.” （無料ではない。推論を実行する必要があり、誰かがそれを推論で高速にする必要がある）

“This is not Linux. You can’t see inside.” （これは Linux ではない。中身は見えない）

従来のオープンソースソフトウェア — Linux、PostgreSQL、React — は、ソースコードを読み、理解し、フォークし、改変できます。ノートパソコン 1 台で動かせます。しかし AI モデルの「重み」は、数百ギガバイトの数値の羅列です。ソースコードのように「読んで理解する」ことはできません。

生成AIで情報漏えいが増える本当の理由 — 「検索者がAIになった」時代の脅威モデルと3層防御

Mon, 02 Mar 2026 00:00:00 +0000

name: security-check description: Claude Code 利用における情報漏えいリスクをチェックする。 Auto Memory や CLAUDE.md への機密混入、.env の gitignore 漏れ、機密ファイルの存在などを検査する。

Claude Code の利用に関する情報漏えいリスクをチェックしてください。

チェック対象

以下の 4 カテゴリを順番に検査する。

1. Auto Memory の機密スキャン

~/.claude/ 配下の memory ファイルを検査する:

以下のパスを Glob で列挙する:
- ~/.claude/projects/*/memory/*.md
- ~/.claude/projects/*/memory/**/*.md
各ファイルを Read で読み込み、以下のパターンを Grep で検出する:
- API キー・トークン: (?i)(api[_-]?key|secret[_-]?key|access[_-]?token|bearer)\s*[:=]\s*\S+
- パスワード: (?i)(password|passwd|pwd)\s*[:=]\s*\S+
- AWS 認証情報: (?i)(AKIA[0-9A-Z]{16}|aws[_-]?secret)
- 接続文字列: (?i)(mysql|postgres|redis|mongodb):\/\/\S+
- 個人情報パターン: メールアドレス、電話番号、マイナンバーらしき数字列
- 金額・契約情報: (?i)(契約金額|単価|請求|売上)\s*[:：]\s*[\d,￥¥$]+
- 顧客 ID の具体値: (?i)(顧客id|customer[_-]?id|ユーザーid|user[_-]?id)\s*[:=：]\s*\d+
検出があれば、ファイルパス・行番号・該当箇所を報告する

2. CLAUDE.md の機密スキャン

プロジェクトの CLAUDE.md およびグローバルの ~/.claude/CLAUDE.md を検査する:

両ファイルを Read で読み込む
チェック 1 と同じパターンで Grep 検査する
加えて、以下も確認する:
- URL にトークンやキーが含まれていないか（?token=, ?key=, ?secret=）
- 内部 IP アドレスやホスト名が含まれていないか
CLAUDE.md はリポジトリにコミットされるため、検出時は即時対応を推奨として強調する

3. 機密ファイルの gitignore チェック

プロジェクトルートで以下を確認する:

東京大学が無料公開した「思考の解像度を上げる」全118スライド -- 深さ・広さ・構造・時間の4軸フレームワーク

Mon, 02 Mar 2026 00:00:00 +0000

東京大学が無料公開した「思考の解像度を上げる」全118スライド – 深さ・広さ・構造・時間の4軸フレームワーク

@MacopeninSUTABA（かずなり｜生成AI×ビジネスハック）氏のポストが話題です。

東京大学が無料公開した「思考の解像度を上げる全ノウハウ」が凝縮された資料が有益。「解像度が低い＝深さ・広さ・構造・時間の不足」という定義から、分析を劇的に深めるテクニック、そして「実装可能」なレベルまで鮮明にする方法まで、余すことなく学べる。

東京大学 FoundX ディレクター・馬田隆明氏が SpeakerDeck で公開しているスライド「解像度を上げる」は、累計 570 万回以上閲覧された「神スライド」として知られています。本記事では、このスライドの核心である「4つの視点」と「48の実践パターン」を掘り下げます。

「解像度」とは何か

ビジネスの現場で「あの人は解像度が高い」という表現を耳にすることが増えました。馬田氏はこの「解像度」を次のように定義しています。

顧客の状況や課題、次に取るべきアクションが鮮明に見えている状態

逆に、解像度が低いとは「思考や事実認識が粗い」状態です。つまり、課題を構成要素に分解できておらず、各要素の理解が浅い状態を指します。

重要なのは、解像度は単に「知識量が多い」ことではないという点です。情報を持っていても、それを構造化し、深く掘り下げ、時間軸で捉えられなければ、解像度は低いままです。

4つの視点

スライドの中核をなすのが、解像度を構成する 4 つの視点です。

視点	問い	低い状態	高い状態
深さ	なぜそうなるのか？	表面的な症状だけを見ている	根本原因まで掘り下げている
広さ	他にどんな可能性があるか？	1つのアプローチしか検討していない	複数の視点・手法を比較している
構造	要素間の関係はどうか？	情報がバラバラで整理されていない	因果関係と優先順位が明確
時間	過去から未来へどう変化するか？	現在のスナップショットだけ	経時変化とプロセスを捉えている

馬田氏が繰り返し強調するのは、4 つの視点のうち最も不足しがちなのは「深さ」であるという点です。多くの人は課題を広く浅く捉えることはできても、1 つの課題を徹底的に掘り下げることが不十分だと指摘しています。

問題と解決策の両面で解像度を上げる

このフレームワークのもう一つの特徴は、解像度を問題側と解決策側の 2 軸で捉える点です。

 問題の解像度 解決策の解像度
深さ 根本原因の特定 実装の具体性
広さ 顧客セグメントの網羅 代替手段の検討
構造 課題間の因果関係 アーキテクチャ設計
時間 課題の変遷 ロードマップ

ビジネスで価値を生むには、「顧客の課題」と「それに対応する解決策」の両方の解像度を上げる必要があります。どちらか一方だけでは不十分です。

48 の実践パターン

書籍版では、4 つの視点ごとに具体的なアクションが「型」として整理されています。「情報 × 思考 × 行動」を組み合わせた 48 のパターンです。代表的なものを紹介します。

# 組織の課題管理から個人のタスク整理と優先度づけへ — Claude Code によるタスクトリアージ

Sun, 01 Mar 2026 00:00:00 +0000

組織の課題管理から個人のタスク整理と優先度づけへ — Claude Code によるタスクトリアージ

各システムの役割と利用者

システム	主な利用者	目的
Backlog	利用者側の責任者・管理部門	利用者が課題を把握・確認するため
Asana	開発会社の PM・経営者	開発会社の責任者が状況を把握するため
GitHub	開発担当者	作業担当者が実装・コード変更を管理するため

3層の責任構造

利用者（顧客） 開発会社（経営・PM） 開発会社（作業担当）
│ │ │
Backlog Asana GitHub
課題確認会で 経営判断・ Issue/PR で
進捗レビュー リソース配分 実装を管理

各システムは異なるステークホルダーが、それぞれの責任範囲で状況を把握するために存在する。これは冗長ではなく、報告先ごとに適切な粒度・視点で情報を提供するための構造。

担当者の課題: 「今何をすべきか」の判断

3システムはどれも他者への報告用であって、担当者が「自分が次に何をやるか」を整理する場所ではない。

システム	読者	自分の優先度確認に使えるか
Backlog	利用者の責任者	△ 顧客視点の優先度であって自分の作業順ではない
Asana	開発会社の経営・PM	△ 経営視点のフィルタがかかっている
GitHub (epm-server)	作業担当者	△ Issue は技術タスク単位で、全体俯瞰しにくい

解決策: Claude Code でタスクトリアージ → プライベートリポジトリの Issue に記録

タスクトリアージ（状況分析と優先度づけ）は Claude Code セッションで行い、結論の記録先は社内プライベートリポジトリの GitHub Issue に置く。

AI エージェント入門 — 元 Meta エンジニアが説く「オートメーションとエージェントの決定的な違い」

Sun, 01 Mar 2026 00:00:00 +0000

AI エージェント入門 — 元 Meta エンジニアが説く「オートメーションとエージェントの決定的な違い」

「AI エージェント」という言葉が溢れる2026年。しかし、本当に「エージェント」と呼べるものはどれだけあるのでしょうか。

@kgsi（こぎそ）さんのポストで紹介されていた、元 Meta ソフトウェアエンジニア Vasuman Moza 氏の「AI Agents 101」は、コードを書く前に理解すべきエージェントの本質を明快に整理しています。

“If you want to learn how to build AI Agents, read this before you write a single line of code.” （AI エージェントの構築を学びたいなら、コードを1行書く前にこれを読め）

この記事では、Vasuman 氏のガイドの要点と、エンジニアが押さえるべきポイントを解説します。

オートメーション vs エージェント — 根本的な違い

最も重要な区別は、指示（instructions） と 目標（goals） の違いです。

	オートメーション	エージェント
入力	事前に決められた手順（指示）	達成すべきゴール（目標）
動作	ルール通りに実行	状況を観察しながら自律的に判断・行動
例外処理	ルール外は停止 or エラー	文脈を理解して適応
代表例	RPA、cron ジョブ、IFTTT	Claude Code、Devin、カスタム AI エージェント

一言で言えば：

Anthropic Wealth Management AI ツール（Claude CoWork）記事要約・考察

Sun, 01 Mar 2026 00:00:00 +0000

Anthropic が Wealth Management 向け AI ツール「Claude CoWork」を発表 — Agentic AI 時代の幕開け

元記事: Agentic AI 101 for Advisors as Anthropic Launches Wealth Management Tools

記事概要

Anthropic が、ウェルスマネジメント（資産管理）業界向けの Claude CoWork プラグイン を発表した。これは金融アドバイザー向けに設計された AI ツールで、ポートフォリオ分析や税務分析、リバランス推奨など、従来人手で行っていた業務を自動化する。

Anthropic は設立5年で従業員約3,000名、シリーズGラウンドで300億ドルを調達し、評価額は3,800億ドルに達している。LPL Financial との関係拡大も発表されており、金融業界への本格参入が明確になった。

Agentic AI の定義 — 4つの要素

Vestmark CTO の Freedom Dumlao 氏は、真の「エージェント」を構成する4つの継続的機能を定義している:

要素	説明
認識（Sense）	環境のコンテキストを認識する — 利用可能なツール、現在のシステム状態
思考（Think）	目標と現在の理解に基づいて、次のステップを独立して推論する
行動（Act）	ツールの使用、データの変更、ワークフローのトリガーなど、観察可能な効果を実行する
記憶（Remember）	インタラクション間で情報を保持し、将来の行動を改善する

「システムが4つ全てを行うなら、それはエージェントです。2つか3つなら、便利なツールかもしれませんが、エージェントと呼ぶのは満たせない期待を設定することになります」 — Freedom Dumlao, Vestmark CTO

この定義は、単なるチャットボットや RAG システムと真のエージェントを区別する明確な基準として有用だ。

Claude CoWork の主要機能

ポートフォリオ分析の自動化

顧客のポートフォリオを自動で分析し、リスク配分やパフォーマンスの洞察を提供する。

Claude Code が汎用AIエージェント基盤へ進化 — Auto Memory・Remote Control・Scheduled Tasks の全貌

Sun, 01 Mar 2026 00:00:00 +0000

Claude Code が「汎用AIエージェント基盤」へ進化 — Auto Memory・Remote Control・Scheduled Tasks の全貌

2026年2月、Anthropic は Claude Code に3つの重要なアップデートを投入しました。これらを組み合わせると、オープンソースの自律AIエージェント OpenClaw に近い体験が、公式機能だけで実現できる可能性が見えてきます。

参考ツイート: @Fujin_Metaverse

3つのアップデート概要

機能	概要	リリース
Auto Memory	AIが自分で学習内容を記憶・蓄積する	2026年2月
Remote Control	スマホからPCのClaude Codeを操作	2026年2月25日
Cowork Scheduled Tasks	指定時間に自動でタスクを実行	2026年2月24日

1. Auto Memory — AIが自分でメモを取り、セッションを超えて記憶する

仕組み

Claude Code がプロジェクトごとに MEMORY.md ファイルを自動作成し、以下のような情報を蓄積していきます。

プロジェクトのビルドコマンド、コードスタイル
アーキテクチャの決定事項
デバッグで解決したトリッキーなバグ
ユーザーのワークフローやコミュニケーションスタイル

技術的な詳細

項目	内容
保存場所	`~/.claude/projects/<encoded-path>/memory/MEMORY.md`
読み込み	セッション開始時に最初の200行をシステムプロンプトに自動注入
Git	ローカル保存のみ。Git にはコミットされない
管理	`/memory` コマンドで確認・編集
無効化	設定ファイルまたは環境変数でオフ可能

CLAUDE.md との違い

CLAUDE.md → ユーザーが手動で書くルール・指示書（チーム共有可能）
MEMORY.md → AIが自動で書く学習メモ（ローカル個人用）

両方を併用するのがベスト。CLAUDE.md でプロジェクトのルールを明示し、MEMORY.md でAIの学習知見を蓄積します。

MCP のトークン消費問題 — スキーマ注入で 55,000 トークン、CLI は 35 倍効率的

Sun, 01 Mar 2026 00:00:00 +0000

MCP のトークン消費問題 — スキーマ注入で 55,000 トークン、CLI は 35 倍効率的

Claude Code や OpenClaw で MCP（Model Context Protocol）を使っている方に知ってほしい事実があります。MCP はスキーマ注入だけで数万トークンを消費しており、同じタスクを CLI 経由で実行すると 35 倍効率的 になるケースがあるのです。

@SuguruKun_ai さんのポストと @shinzizm2 さんのポストでこの問題が指摘され、大きな反響を呼びました。

MCP のトークン消費問題とは

スキーマ注入の仕組み

MCP サーバーを接続すると、ツール定義（スキーマ）がシステムプロンプトに注入されます。これは AI が「どんなツールを使えるか」を理解するために必要な情報ですが、この定義自体が大量のトークンを消費します。

MCP サーバー接続時の処理:
1. tools/list でツール一覧を取得
2. 各ツールの名前、説明、パラメータ定義を取得
3. 全てのスキーマをプロンプトに注入 ← ここで大量消費
4. ユーザーの質問に回答

あなたが何も入力する前に、スキーマだけでトークンが消費されているのです。

具体的な数値

MCP サーバー	ツール数	トークン消費量
GitHub MCP サーバー	93 ツール	約 55,000 トークン
Notion サーバー	15+ ツール	約 8,000 トークン
ファイルシステム	10 ツール	約 4,000 トークン
平均的なツール定義	1 ツール	300〜600 トークン

GitHub MCP サーバーの場合、93 ツール分のスキーマには owner、repo、title 等のプロパティ定義、required フィールド、入出力スキーマが全て含まれます。

Sentry × Claude Code で実現する AI デバッグワークフロー — エラー監視から自動修正まで

Sun, 01 Mar 2026 00:00:00 +0000

Sentry × Claude Code で実現する AI デバッグワークフロー — エラー監視から自動修正まで

「バグが起きたら Sentry が検知し、AI が分析して修正案を出す」— そんなワークフローが現実になっています。

@riku720720（Rikuo）さんのポストは、この流れを端的にまとめています。

「アプリ開発する上でsentryは必須。sentry APIをskillsにすればユーザーのバグとか不具合とか全部分析できる。claudecodeの新機能/batchで一気に改善してもらう」

この記事では、Sentry の全体像から Claude Code との連携、そして実践的なワークフローまでを解説します。

Sentry とは

Sentry は、開発者ファーストのエラートラッキング＆パフォーマンス監視プラットフォームです。100以上のプラットフォーム・フレームワーク、30以上のプログラミング言語に対応しています。

単なるエラーログではない

Sentry が他のログ監視ツールと異なるのは、エラーの文脈（コンテキスト）を自動収集する点です。スタックトレースだけでなく、ユーザーのセッション情報、パフォーマンスデータ、リリースバージョンなど、デバッグに必要な情報を一元化します。

Sentry の主要機能

1. Error Monitoring（エラー監視）

Sentry の中核機能です。

リアルタイム検知：エラー発生を即座にキャッチ
インテリジェントグルーピング：同じ原因のエラーを自動的に1つの Issue にまとめる
アラート通知：Slack、メール、PagerDuty 等と連携

1
2
3
4
5
6
7
8


# Django での導入例
import sentry_sdk

sentry_sdk.init(
 dsn="https://xxx@xxx.ingest.sentry.io/xxx",
 traces_sample_rate=1.0,
 profiles_sample_rate=1.0,
)

2. Performance Monitoring（パフォーマンス監視）

分散トレーシング：リクエストの流れをフロントエンドからバックエンドまで追跡
トランザクション分析：遅いエンドポイントやクエリを特定
Web Vitals：LCP、FID、CLS などフロントエンドのパフォーマンス指標

3. Session Replay（セッションリプレイ）

ユーザーのセッションをビデオのように再生できる機能です。

Sentry を Claude Code で置き換えられるか — ランタイム計装と AI 分析の境界線

Sun, 01 Mar 2026 00:00:00 +0000

Sentry を Claude Code で置き換えられるか — ランタイム計装と AI 分析の境界線

エラー監視ツール Sentry が提供する機能の多くは、Claude Code のようなAI コーディングエージェントで代替できるのではないか — LLM の分析能力が向上した2026年、この疑問は自然なものです。

結論から言えば、分析レイヤーは Claude Code で代替可能（むしろ得意）であり、データ収集レイヤーもスタックがパターン化されていれば自前の共通ライブラリで実装可能です。この境界線を正しく理解することが、最適なエラー監視体制を組む鍵になります。

エラー監視の3層構造

エラー監視は、以下の3つのレイヤーで構成されています。

エラー監視 = データ収集（ランタイム計装） + データ蓄積（基盤） + 分析（判断）

レイヤー	Sentry	Claude Code で代替した場合
データ収集	SDK がランタイムに計装	??? （ここが問題）
データ蓄積	Sentry のイベント基盤	CloudWatch / 自前ログ基盤
分析	Seer / ダッシュボード	Claude Code（MCP / バッチ）

Claude Code が強力なのは右端の「分析」レイヤーです。しかし、左端の「データ収集」が貧弱だと、分析対象のデータ自体が不足します。

Claude Code で代替できる部分

1. インテリジェントグルーピング → LLM の方が得意

Sentry はフィンガープリント（スタックトレース + 例外型 + メッセージの組み合わせ）でエラーを集約します。これはルールベースのアルゴリズムです。

クラウド LLM の地政学リスクが顕在化 — ローカル LLM 移行を本気で考える時

Sun, 01 Mar 2026 00:00:00 +0000

クラウド LLM の地政学リスクが顕在化 — ローカル LLM 移行を本気で考える時

2026年2月末、AI 業界に衝撃が走りました。Anthropic が米国防総省からブラックリスト指定を受け、Google の Gemini がイスラエル軍に無断提供されていた疑惑が浮上。@wmoto_ai（生ビール）さんのポストは、多くのエンジニアが感じた危機感を端的に表現しています。

「イスラエルの件、Anthropicの件然り一気に物騒になってきたので本気でローカルLLMへの移行先決めとかないとな..」

この記事では、2つの事件の背景と、クラウド LLM 依存が孕むリスクを整理します。

事件1: Anthropic vs 米国防総省 — AI 安全性を巡る全面対立

何が起きたか

2026年2月、米国防長官 Pete Hegseth は Anthropic に対し、Claude の軍事利用におけるセーフガード（安全装置）の全面撤廃を要求しました。

Anthropic が拒否したかったのは、以下の2点です。

米国民に対する大量監視 への Claude の利用
人間の関与なしに発射する自律兵器 への Claude の利用

時系列

日付	出来事
2月16日	Pentagon が Anthropic との関係見直しを示唆
2月25日	ブラックリスト化の第一歩が報道
2月26日	Hegseth が 2/27 17:01 を最終期限に設定。Anthropic CEO Dario Amodei が拒否を表明
2月27日	トランプ政権が Anthropic を「サプライチェーンリスク」に指定、政府業務から排除
2月27日	OpenAI が即座に国防総省との契約を発表
2月28日	シリコンバレー全体への影響が報道される

Dario Amodei の声明

“We cannot in good conscience accede to their request.” （彼らの要求に良心に従って応じることはできない）

バイブコーディングでデザインを劇的に改善する方法 — UI コンポーネント名で「構造」を指示する

Sun, 01 Mar 2026 00:00:00 +0000

バイブコーディングでデザインを劇的に改善する方法 — UI コンポーネント名で「構造」を指示する

バイブコーディング（Vibe Coding）で AI にUIを作らせると、「動くけどダサい」「素人っぽい」という壁にぶつかる人は多いでしょう。

@7_eito_7（えいと）さんのポストは、この問題に対するシンプルかつ強力な解決策を提示しています。

「バイブコーディングでデザインを20倍よくする裏技。それはUIの種類を覚えること。2,500以上のデザイン例がまとまったThe Component Galleryでデザインの知識を増やす。そして『App Bar + Drawer + Card Grid + Tabs構成で』みたいに構造で指示するだけで一瞬でプロっぽくなる。」

核心は**「見た目」ではなく「構造」で指示する**ことです。

なぜ「きれいにして」では良いUIにならないのか

バイブコーディングでよくある失敗パターンを見てみます。

❌ 曖昧な指示:
「もっとおしゃれにして」
「プロっぽいデザインにして」
「モダンな感じで」
→ AI は「統計的に平均的な」デザインを返す
→ 紫グラデーション、Inter フォント、角丸カードの量産（AI スロップ）

✅ 構造で指示:
「App Bar + Drawer + Card Grid + Tabs 構成で」
「Hero + 3カラム Feature Grid + Testimonial Carousel + CTA Footer で」
「Sidebar Navigation + Data Table + Filter Bar + Pagination で」
→ AI はコンポーネントの「正しい組み合わせ方」を知っている
→ 実在のデザインシステムに基づいた構造が生成される

この違いが生まれる理由は明確です。LLM の学習データには Material Design、Fluent UI、Ant Design など実在のデザインシステムのコードが大量に含まれています。コンポーネント名で指示すると、AI はそれらのデザインシステムの「正しい実装パターン」を参照して出力します。

非エンジニアでも安心！Claude Code を安全に使うための 2 つの設定ファイル（settings.local.json と CLAUDE.md）

Sun, 01 Mar 2026 00:00:00 +0000

非エンジニアでも安心！Claude Code を安全に使うための 2 つの設定ファイル

Claude Code は強力なツールですが、ファイルの削除やシステムコマンドの実行など、意図しない操作が起きる可能性もあります。@tetumemo さんのポストでは、非エンジニアが Claude Code を安全に使うために設定すべき 2 つのファイルが紹介されています。

「包丁」に例えると、settings.local.json は安全カバー（物理的に危険な操作を防ぐ）、CLAUDE.md は『危ないから気をつけて』という声かけ（AI に判断基準を与える）。両方揃って初めて安全性が確保されるという、分かりやすい整理です。

1. settings.local.json — 「仕組みとして」操作を制限する

settings.local.json とは

Claude Code の権限設定ファイルです。AI がどのコマンドを実行でき、どのコマンドを実行できないかを JSON で定義します。

設定ファイルは .claude/settings.local.json に配置します。.local が付くファイルは自動的に .gitignore に追加されるため、個人の設定がチームに影響しません。

基本構造

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


{
 "permissions": {
 "allow": [
 "許可するコマンドやツール"
 ],
 "deny": [
 "禁止するコマンドやツール"
 ]
 }
}

非エンジニア向け推奨設定

@tetumemo さんが紹介しているのは、以下のような設定方針です。

Claude Code の Auto Memory（MEMORY.md）を理解する — CLAUDE.md との使い分け

Sat, 28 Feb 2026 00:00:00 +0000

Claude Code の Auto Memory（MEMORY.md）を理解する — CLAUDE.md との使い分け

Claude Code には「メモリ」と呼ばれる仕組みがセッション間で情報を引き継ぐために用意されています。最近 SNS でも話題になっている Auto Memory（MEMORY.md） について、CLAUDE.md との違いや実践的な活用法を整理します。

きっかけ：SNS での反応

@L_go_mrk さんのポストでは、Claude Code の Auto Memory 機能について「かなり気が利いている」と評価されていました。ポイントは以下の通りです：

「これ覚えておいて！」と指示するだけで、Claude が自動的に重要情報を記憶してくれる
CLAUDE.md（ルール特化）と MEMORY.md（学習・記憶特化）で情報が適切に分離されている
プロジェクトごとに独立した記憶で、他プロジェクトに影響しない
セッション間で記憶が維持される

この指摘はまさにその通りで、CLAUDE.md と MEMORY.md は目的が異なる二つの記憶層として設計されています。

二つの記憶層：CLAUDE.md vs MEMORY.md

CLAUDE.md — 「指示書」

CLAUDE.md はあなたが書いて Claude に従わせるルールです。

コーディング規約、ビルドコマンド、テスト手順
プロジェクトのアーキテクチャや設計方針
チーム全体で共有する約束事

# プロジェクトルール
- テストは pytest で実行: `pytest -xvs`
- コミットメッセージは Conventional Commits に従う
- API 変更時は必ず OpenAPI スキーマを更新する

CLAUDE.md はリポジトリにコミットしてチームで共有することが想定されています。

MEMORY.md — 「学習ノート」

MEMORY.md はClaude 自身が書く、作業を通じた学習メモです。

なぜ AI は同じ紫グラデーションのサイトを作るのか — 分布的収束と Skills による脱却

Sat, 28 Feb 2026 00:00:00 +0000

なぜ AI は同じ紫グラデーションのサイトを作るのか — 分布的収束と Skills による脱却

「AI にランディングページを作らせると、どれも同じに見える」

Inter フォント、白背景に紫グラデーション、角丸カード、3カラムのアイコン付きグリッド — いわゆる AI スロップ（AI slop） と呼ばれるこの現象には、明確な技術的原因があります。

@awakia さんのポストでは、Anthropic が公式ブログで解説した 分布的収束（Distributional Convergence） という概念と、その解決策としての Skills アプローチを紹介しています。差を生むのはモデルの性能ではなく「方向付け」だという指摘は、AI を使ったフロントエンド開発に携わる全ての人にとって重要な示唆です。

分布的収束（Distributional Convergence）とは

LLM はトークンの出現確率に基づいてテキストを生成します。フロントエンドのコード生成においても同じ原理が働きます。

学習データには膨大な数の Web サイトのソースコードが含まれていますが、その中で 最も頻出する「安全な」選択肢 が統計的に支配的です。結果として、指示なしで「ランディングページを作って」と頼むと、学習データの 中央値 に収束した出力が生成されます。

なぜ「紫」なのか

この疑問には具体的な答えがあります。約 5 年前、Tailwind CSS のデフォルトボタンカラーが indigo-500 に設定されました。その後、GitHub 上に大量の Tailwind チュートリアルやサンプルコードが蓄積されました。AI に制約なしで「ランディングページを作って」と指示すると、2019 年から 2024 年にかけてスクレイピングされた Tailwind CSS チュートリアルの中央値を得ることになります。そして、その中央値が紫なのです。

AI スロップの典型パターン

要素	AI スロップの典型
フォント	Inter, Roboto, Arial, system fonts
配色	白背景 + 紫/インディゴグラデーション
レイアウト	3カラムのカード型グリッド
角丸	控えめだが均一な rounded-lg
アニメーション	なし、または最小限
背景	単色（白 or 薄いグレー）

これは「悪い」デザインではなく、統計的に平均的なデザインです。どのプロジェクトにも合いそうで、どのプロジェクトにも合わない — そういう出力になります。

# 【2026年最新】世界一わかりやすい Agent Skills 完全ガイド — まとめ

Fri, 27 Feb 2026 00:00:00 +0000

【2026年最新】世界一わかりやすい Agent Skills 完全ガイド — まとめ

元記事: 【2026年最新】世界一わかりやすいAgent Skills完全ガイド（株式会社AIworker）紹介ポスト: Fujin(@fujin_metaverse)

Agent Skills とは？

一言で言うと、「AIエージェントに渡す新人研修マニュアル」。

会社の新入社員にマニュアルを渡すのと同じ要領で、SKILL.md というテキストファイルに「やり方」を書いて所定のフォルダに置くだけ。AIエージェントが自動的にそれを見つけて読み込み、指示通りに仕事をしてくれる。

2025年12月に Anthropic がオープンスタンダードとして公開
Claude, GitHub Copilot, OpenAI Codex, Cursor など主要AIツールが対応
2026年2月時点でマーケットプレイス登録数は20万件超

なぜ Agent Skills が必要か — プロンプトの3つの限界

従来のプロンプト運用には以下の限界があった。Agent Skills はこれらを全て解決する。

限界	問題	Agent Skills での解決
毎回同じ説明が必要	技術スタック、規約、コミットルールを毎回ゼロから伝える	一度書けば繰り返し使える
チーム共有できない	優れたプロンプトがチャット履歴に埋もれる	Git で管理・共有可能
コンテキスト圧迫	毎回全情報を読み込むと、肝心のタスクの余裕が減る	必要な時に必要な分だけ読み込む「段階的開示」

Claude Code のセットアップ手順

Agent Skills を使う最も一般的な環境は Claude Code（Anthropic 提供のターミナル型AIコーディングツール）。ブラウザ版の Claude.ai と違い、PCのファイルを直接読み書きできるのが特徴。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 1. Node.js の確認（v18.0.0 以上が必要）
node --version

# 2. Claude Code のインストール（Mac / Linux）
curl -fsSL claude.ai/install.sh | bash

# 3. 確認
claude --version

# 4. 初回起動（ブラウザでログイン画面が開く）
mkdir ~/my-project && cd ~/my-project
claude

SKILL.md の書き方

SKILL.md は YAMLフロントマター + Markdown 本文 の2部構成。

# Anthropic 社内チームの Claude Code 活用 — マーケから法務まで、全部門が「自分で自動化」する時代

Fri, 27 Feb 2026 00:00:00 +0000

Anthropic 社内チームの Claude Code 活用 — マーケから法務まで、全部門が「自分で自動化」する時代

Anthropic 公式記事: How Anthropic teams use Claude Code 再現記事: Claude Code で広告バナー200本を15分で作る手順紹介ポスト: commte

はじめに

Anthropic が「自社のチームが Claude Code をどう使っているか」を公式ブログで公開した。注目すべきは、エンジニアリングチームだけでなく、マーケティング、法務、データサイエンス、デザインといった非技術部門が、コードを1行も書かずに高度な自動化を実現している点。

特にマーケティングチームの事例は、ツイートでも「えぐい広告手法」として話題になり、実際に再現して15分で広告バナー200本を生成した記事も登場した。

マーケティングチーム — たった1人で10倍の成果

チーム構成

驚くべきことに、Anthropic のグロースマーケティングチームはエンジニアがゼロの1人チーム。担当の Austin Rau 氏は、元々ターミナルの開き方すら知らなかったという。

それが、非技術者向けガイドを見てから1週間で、Figma プラグインと広告コピー生成ワークフローの両方を構築した。

4つの自動化事例

1. Google Ads の広告コピー生成（2時間 → 15分）

数百件の既存広告 CSV を Claude Code に読み込ませ、パフォーマンスの低い広告を自動特定。改善案をサブエージェント方式で生成する。

サブエージェント設計のポイント:

エージェント	専門	制約
headline-writer	見出し生成	30文字以内
description-writer	説明文生成	90文字以内

1つのプロンプトで全部やらせるのではなく、タスクごとに専門エージェントを分けることで、文字数制約を守りつつ品質を維持する。

2. Figma プラグインでバナー一括生成（数時間 → 0.5秒）

Claude Code で自作した Figma プラグインが、テンプレートのテキストノードを CSV データで自動差し替え。最大100パターンのバナーを一括生成する。

# Claude Code の「YOLO モード」を安全に使う — dangerously-skip-permissions と Docker 活用

Fri, 27 Feb 2026 00:00:00 +0000

Claude Code の「YOLO モード」を安全に使う — dangerously-skip-permissions と Docker 活用

関連ポスト: hiragram リポジトリ: hiragram/claude-docker

はじめに

Claude Code を使っていると、ファイル編集やコマンド実行のたびに「これを実行してもいいですか？」と確認を求められる。安全設計として正しいが、反復的な作業では毎回の承認が煩わしくなる。

そこで登場するのが --dangerously-skip-permissions フラグ。通称「YOLO モード」。YOLO とは “You Only Live Once”（人生は一度きり） の略で、「結果を気にせず、とにかくやってしまえ」というネットスラング。安全確認を一切スキップして全操作をぶっ通しで実行させる様子が、まさに「後先考えずに突っ走る」YOLOの精神そのものであることから、コミュニティでこう呼ばれるようになった。

便利だが、名前の通り危険も伴う。このフラグの本質と、安全に使うための Docker 活用について整理する。

`--dangerously-skip-permissions` とは

Claude Code の全てのパーミッションチェック（権限確認プロンプト）をバイパスし、完全に自律動作させるフラグ。

1

claude --dangerously-skip-permissions

3つの動作モードの比較

モード	挙動	ユーザー介入
通常モード	ファイル変更・コマンド実行のたびに承認を要求	毎回必要
Auto-Accept (Shift+Tab)	UI上で承認を自動化	介入可能
dangerously-skip-permissions	全ての安全ガードレールを除去	一切不要

なぜ「dangerously」と名付けられているのか

Anthropic が意図的に「危険」という語を含めている。実際にリスクは深刻で、以下のような報告がある。

Wolak 事件（2025年10月）: Ubuntu/WSL2 上で Claude Code が rm -rf / を実行し、/bin、/boot、/etc などシステムディレクトリを破壊
eesel AI の調査によると、このフラグ使用者の 32% が意図しないファイル変更を経験、9% が実際のデータ損失を報告

主なリスク

リスク	具体例
破壊的コマンドの無確認実行	`rm -rf`、`git reset --hard`、設定ファイル上書き
スコープクリープ	指定範囲外のファイルを「親切心」で変更・削除
資格情報の漏洩	ホストの全資格情報にアクセス可能な状態
連鎖的被害	1つの誤った解釈が次々と問題を引き起こす

それでも YOLO モードが必要な理由

危険だが、以下のユースケースでは事実上不可欠。

# Claude Code の能力を10倍にする CLAUDE.md — AI エージェントのマネジメント哲学

Fri, 27 Feb 2026 00:00:00 +0000

Claude Code の能力を10倍にする CLAUDE.md — AI エージェントのマネジメント哲学

紹介ポスト: チャエン @masahirochaen 解説記事: Zenn: Claude Codeの能力を10倍にする CLAUDE.md の中身を見てみた

はじめに

海外で大バズりした「Claude Code の能力を10倍にする CLAUDE.md」。Anthropic の Claude Code 開発者が実際に使っているベストプラクティスを、1つの CLAUDE.md ファイルに構造化したもの。

これは単なるプロンプトテンプレートではない。AI エージェントをどうマネジメントするかという哲学を、実装可能な形にまとめたファイルだ。

6つのワークフロー原則

1. Plan Mode デフォルト

「3ステップ以上、またはアーキテクチャ判断を伴うタスクは、必ず Plan Mode から始めよ」

Claude Code が実装に飛びつくのを防ぐ最も重要なルール。計画なしに実装を始めると、途中で方向修正が必要になったとき、修正の連鎖（カスケード失敗）が発生する。

やり方:

Shift+Tab を2回押して Plan Mode に入る
Claude の計画が納得できるまでやり取りを繰り返す
計画が固まったら Auto-Accept モードに切り替えて一気に実装

実行中に問題が起きたら:

すぐに Plan Mode に戻って再計画する
Plan Mode は「最初の設計」だけでなく「リカバリー」にも使う

2. サブエージェント戦略

「リサーチ、探索、並列分析はサブエージェントに委譲せよ」

メインのコンテキストウィンドウは有限のリソース。調査や分析をメインエージェントにやらせると、コンテキストが汚れて本来のタスクの品質が下がる。

サブエージェントに委譲すべきタスク:

コードベースの調査・探索
複数ファイルの並列分析
計算集約的な処理
独立した検証作業

メインエージェントに残すべきタスク:

最終的な設計判断
コードの実装
統合・結合

初心者向け解説: 「サブエージェント（Task）」とは何か

「サブエージェント」と聞くと難しそうだが、仕組みはシンプル。Claude Code が内部的に「別の Claude」を立ち上げて、作業を分担する機能のこと。Claude Code ではこれを Task と呼ぶ。

# Claude Code 開発者が教える CLAUDE.md と実践 Tips

Fri, 27 Feb 2026 00:00:00 +0000

Claude Code 開発者が教える CLAUDE.md と実践 Tips

元スレッド（個人セットアップ編）: Boris Cherny @bcherny（53K いいね、780万ビュー）元スレッド（チーム Tips 編）: Boris Cherny @bcherny（49K いいね、850万ビュー）紹介ポスト: すぐる @sugurukun_ai 設定再現リポジトリ: 0xquinto/bcherny-claude

はじめに

Claude Code の開発者である Boris Cherny 氏が、自身のセットアップと Claude Code チーム全体の使い方を X で公開し、合計 10 万いいね以上を獲得して大きな話題になった。

この記事では、2つのスレッドの内容を統合して「CLAUDE.md の育て方」と「Claude Code を最大限活用する 10 の Tips」をまとめる。

CLAUDE.md とは

CLAUDE.md は、Claude Code がセッション開始時に自動的に読み込むプロジェクトの指示書。新入社員に渡すオンボーディングドキュメントのようなもので、以下を記述する:

プロジェクトの技術スタック・アーキテクチャ
コーディング規約・命名ルール
よく使うコマンド
過去に Claude が犯した間違いと対策
やってはいけないこと

配置場所

ファイル	スコープ
`~/.claude/CLAUDE.md`	全プロジェクト共通（個人設定）
`プロジェクトルート/CLAUDE.md`	そのプロジェクト限定（チーム共有・Git 管理）

Boris Cherny のセットアップ（スレッド1）

1. 並列セッション

Boris はターミナルで 5 つの Claude を同時に並列実行している。さらに claude.ai/code 上でも 5〜10 個を並行稼働させ、システム通知で完了を監視する。

# Claude Projects × GitHub 同期 — AI のメモリより精度が高いナレッジ管理

Fri, 27 Feb 2026 00:00:00 +0000

Claude Projects × GitHub 同期 — AI のメモリより精度が高いナレッジ管理

紹介ポスト: yriica 「ClaudeのProjects内のFilesにGitHubリポジトリを同期できることが判明。GitHubリポジトリに日報含めいろんなデータをプッシュしておいたことで、その内容をふまえた上でClaudeでチャットができるようになった。AIのメモリ機能よりもこちらのほうが回答精度が高い。」

はじめに

Claude.ai（ブラウザ版）の Projects 機能に、GitHub リポジトリのファイルを直接同期できる機能がある。日報、議事録、設計メモなど、普段の業務で Git に蓄積していたドキュメントが、そのまま Claude の高精度なコンテキストとして機能する。

これは「AI のために特別なことをした」のではなく、普段の業務として Git にドキュメントを蓄積していたものが、AI 活用で大きなアドバンテージになったという事例。

Claude Projects の GitHub 連携とは

基本機能

Claude.ai の Projects には「プロジェクトナレッジ」としてファイルを追加できる。ここに GitHub リポジトリを接続すると:

リポジトリ内のファイル名と内容が Claude に読み込まれる
「Sync now」ボタンで最新のコミット内容に更新できる
複数リポジトリを1つのプロジェクトに追加可能
プライベートリポジトリにも対応（GitHub App 経由で権限付与）

設定方法

チャット内から追加する場合:

左下の「+」ボタンをクリック
ドロップダウンから「Add from GitHub」を選択
ファイルブラウザで特定のファイルやフォルダを選択
メッセージ送信時に Claude がコンテンツを処理

プロジェクトナレッジとして追加する場合:

プロジェクト知識セクションの右上「+」をクリック
「GitHub」を選択
リポジトリを検索、または URL を貼り付け
ファイルブラウザで対象を指定
プロジェクトナレッジに追加

同期の仕組み

特定ブランチのファイル名とコンテンツのみが同期される
コミット履歴、PR、Issue などのメタデータは取得されない
「Sync now」ボタンで手動更新（自動同期ではない）
大きな変更がある前に同期を実施するのがベストプラクティス

制限事項

複数リポジトリ追加時は Claude のコンテキストウィンドウに収まる必要がある
現在ベータ版
トークン制限を考慮した戦略的なファイル選択が重要

なぜ「メモリ機能より精度が高い」のか

Claude にはチャットの中から情報を学習する「メモリ」機能があるが、GitHub 同期とは根本的に性質が異なる。

# git-lrc — コミット時に AI が無料でコードレビューしてくれるツール

Fri, 27 Feb 2026 00:00:00 +0000

git-lrc — コミット時に AI が無料でコードレビューしてくれるツール

リポジトリ: HexmosTech/git-lrc 紹介ポスト: commte

これは何か

git-lrc は、git commit のタイミングで自動的に AI コードレビューが走るツール。Git フックとして動作し、コミット前の差分を AI（Google Gemini）に分析させ、バグやセキュリティ問題をブラウザ上の UI でインラインコメントとして表示してくれる。

しかも Gemini の無料枠を使うので完全無料。

なぜこれが作られたのか

AI エージェント時代の新しい問題

Claude Code や Cursor などの AI コーディングエージェントは、コードを高速に生成する。しかし同時に、黙ってロジックを削除したり、挙動を変えたり、バグを混入させることもある — しかもユーザーに何も言わずに。

問題に気づくのは、たいてい本番環境にデプロイした後。

既存のコードレビューの限界

PR レビュー: チームメンバーの時間を消費する。AI 生成コードの量が増えるとレビューが追いつかない
手動チェック: 大量の差分を毎回目視確認するのは非現実的
CI/CD のテスト: テストがカバーしていない箇所の論理変更は検出できない

git-lrc のアプローチ

「コミット」という全開発者が必ず通るポイントにフックすることで、レビュー漏れをほぼゼロにする。エディタや AI ツールキットが何であっても、Git は共通基盤。コミットは必須操作なので、スタックに関係なくレビューが走る。

どう動くのか

セットアップ（約1分、1回だけ）

1
2
3
4
5


# インストール（Mac / Linux）
curl -fsSL https://hexmos.com/lrc-install.sh | sudo bash

# 初期設定（ブラウザで API キーを取得）
git lrc setup

必要なのは2つ:

# コンテキストエンジニアリング — AI を「使う人」と「使いこなす人」の違い

Fri, 27 Feb 2026 00:00:00 +0000

コンテキストエンジニアリング — AI を「使う人」と「使いこなす人」の違い

紹介ポスト: えいと @7_eito_7 「AIを使っている人と、本当にAIを使いこなしている人の違いは何か。結論はコンテキストエンジニアリングができるかどうか。簡単に言えば、指示の出し方ではなくどんな文脈を渡しているか。」

はじめに

2025年半ば、Shopify CEO の Tobi Lütke が次のように発言した:

「“プロンプトエンジニアリング"より"コンテキストエンジニアリング"という言葉の方がずっと好きだ。LLM がタスクを解決できるだけの十分な文脈を与える技術 — これこそが核心的スキルだ。」

AI 研究者の Andrej Karpathy もこれに同意し、「コンテキストエンジニアリング」という概念は一気に広まった。2026年現在、プロンプトエンジニアリングの時代は終わり、コンテキストエンジニアリングが AI 活用の新しい標準になりつつある。

プロンプトエンジニアリング vs コンテキストエンジニアリング

観点	プロンプトエンジニアリング	コンテキストエンジニアリング
スコープ	1つの入力テキストの書き方	モデルが見る情報の全体設計
焦点	指示の言い回し・構造	情報の選択・順序・形式・量
対象	単発の質疑応答	複雑な推論、マルチターン、エージェント
複雑さ	文章レベル	システムレベルのパイプライン
例え	「質問の仕方を工夫する」	「解答に必要な教科書・資料・道具を揃える」

プロンプトエンジニアリングはコンテキストエンジニアリングの一部にすぎない。質問の質ではなく、AI に渡す情報の質と構造が結果を決める。

なぜプロンプトだけでは不十分なのか

よくある問題: RAG で正確な情報を取得し、プロンプトも丁寧に書いた。それでも AI がハルシネーションを起こす。

原因はプロンプトでも検索でもなく、コンテキストの構造にある。

プロンプトの 3 つの限界

情報不足: 質問は完璧でも、判断に必要な背景情報が足りない
情報過多: 関連情報を全部詰め込むと、かえって精度が落ちる（ノイズに埋もれる）
情報の無秩序: 重要な情報とそうでない情報が区別なく並んでいる

コンテキストエンジニアリングは、この 3 つを体系的に解決する。

コンテキストエンジニアリングの 4 つの柱

1. 構成（Composition）— 何を渡すか

タスクに必要な「材料」を選択する:

# 三菱UFJ銀行におけるエンタープライズAI駆動開発のリアル

Fri, 27 Feb 2026 00:00:00 +0000

三菱UFJ銀行におけるエンタープライズAI駆動開発のリアル

三菱UFJインフォメーションテクノロジー（MUIT）R&D部尾根田倫太郎氏の講演まとめ出典: SpeakerDeck

エンタープライズAI駆動開発とは

AI駆動開発とは、AIコーディングエージェントを前提とした開発方式のこと。従来の人海戦術的な開発と異なり、自然言語での指示により複数のソースコードが短時間で自動生成される。

三菱UFJ銀行（MUFG）では、この手法を金融システムの内製開発に適用する取り組みを進めている。

エンタープライズ特有の条件

一般的なAI駆動開発と異なり、銀行システムには以下の制約がある。

数十万〜数百万行規模のシステム
数十〜数百人規模のチーム
Excel方眼紙での設計書作成が標準
インターネット非接続環境での開発

主要ツールとして Cline または Claude Code を採用している。

Agent Skills — AIへの「教科書」

Agent Skills は、AIコーディングエージェントに教科書として機能するマークダウンファイルとして定義されている。2025年12月に Agentic AI Foundation により標準規格化された。

従来は「人への教育」が中心だったが、今後はAIエージェントへの教育へシフトするという発想の転換が示された。

Agent Skills とは何か

Agent Skills は、AIエージェントに新しい能力や専門知識を与えるための、フォルダ単位でパッケージ化された手順書・スクリプト・リソースの集合体である。エージェントが必要に応じてスキルを発見・読み込み、タスクをより正確かつ効率的にこなせるようにする仕組み。

公式サイト: agentskills.io

なぜ Agent Skills が必要か

AIエージェントは汎用的な能力は高いが、特定の企業・チーム・ドメイン固有のコンテキストを持っていない。Agent Skills はこのギャップを埋める。

対象	メリット
スキル作成者	一度作れば複数のエージェント製品で横断的に利用可能
エージェント開発者	Skills 対応するだけでエンドユーザーが機能拡張できる
企業・チーム	組織の知識をバージョン管理可能なパッケージとして蓄積

SKILL.md の基本構造

Agent Skills の実体は、SKILL.md というマークダウンファイルを含むフォルダ。YAMLフロントマターでメタデータを定義し、本文に手順を記述する。

skill-name/
├── SKILL.md # 必須: メタデータ + 手順
├── scripts/ # 任意: 実行可能スクリプト
├── references/ # 任意: 補足ドキュメント
└── assets/ # 任意: テンプレート、画像等

SKILL.md の例:

Agent Plugins for AWS — AI コーディングエージェントに AWS の専門知識を装着する

Fri, 27 Feb 2026 00:00:00 +0000

Agent Plugins for AWS — AI コーディングエージェントに AWS の専門知識を装着する

紹介ポスト: moritalous 公式ブログ: Introducing Agent Plugins for AWS | AWS Developer Tools Blog リポジトリ: awslabs/agent-plugins

はじめに

2026年2月、AWS は Agent Plugins for AWS をオープンソースで公開した。Claude Code や Cursor といった AI コーディングエージェントに AWS の専門知識を「スキル」として装着するプラグインライブラリである。

これは単なる CLI ラッパーではない。AI エージェントがアーキテクチャ設計 → コスト見積もり → IaC 生成 → デプロイまでを一貫して実行できる「AWS ドメイン能力層」を追加するもの。

従来: 開発者が AWS ドキュメントを読み → 設計を考え → CDK/CFn を書き → デプロイ
今後: 「deploy to AWS」と言うだけ → AI が全工程を実行（人間は確認・承認のみ）

Agent Plugin とは何か

プラグインの構成要素

Agent Plugin は4つの部品を1つのパッケージにまとめたもの。

AI は会話が長くなるほど「迷子」になる — Microsoft × Salesforce の研究解説

Fri, 27 Feb 2026 00:00:00 +0000

AI は会話が長くなるほど「迷子」になる — Microsoft × Salesforce の衝撃の研究

紹介ポスト: kosuke_agos 論文: LLMs Get Lost In Multi-Turn Conversation Microsoft Research: 公式ページ

はじめに

「AI と長く会話するほど、AI の知能が劣化する」— これは体感ではなく、Microsoft Research と Salesforce Research が 20万件以上の AI 会話を分析 して科学的に証明した事実である。

論文タイトルは “LLMs Get Lost In Multi-Turn Conversation”（LLM はマルチターン会話で迷子になる）。GPT-4.1、Claude 3.7 Sonnet、Gemini 2.5 Pro を含む 15 モデル全てで、会話が長くなるほど性能が劇的に低下することが明らかになった。

衝撃の数字

指標	数値
平均性能低下	39%
不安定性（unreliability）の増大	+112%
精度の変化	90% → 約 51%
テストしたモデル数	15（大小問わず全て劣化）

最も重要な発見: 高性能モデルも小型モデルも、同じように劣化する。

Claude 3.7 Sonnet、Gemini 2.5 Pro、GPT-4.1 といったトップモデルでも 30〜40% の性能低下が観測された。モデルの「賢さ」では回避できない、構造的な問題であることが判明した。

研究チームと手法

著者

名前	所属
Philippe Laban	Microsoft Research
Hiroaki Hayashi	Salesforce Research
Yingbo Zhou	Salesforce Research
Jennifer Neville	Microsoft Research

テスト対象モデル（15種）

OpenAI: GPT-4o-mini, GPT-4o, o3, GPT-4.1
Anthropic: Claude 3 Haiku, Claude 3.7 Sonnet
Google: Gemini 2.5 Flash, Gemini 2.5 Pro
Meta: Llama 3.1-8B, Llama 3.3-70B, Llama 4 Scout
その他: Microsoft Phi-4, AI2 OLMo-2-13B, Deepseek-R1, Cohere Command-A

Sharding（シャーディング）— 現実の会話を再現する手法

ユーザーは通常、最初から完璧な指示を出さない。

Claude Code に重大な脆弱性 — リポジトリを開くだけで任意コード実行の恐れ

Thu, 26 Feb 2026 00:00:00 +0000

Claude Code に重大な脆弱性 — 「リポジトリを開くだけ」で任意コード実行の恐れ

セキュリティ企業 Check Point が、Anthropic の AI コーディング支援ツール Claude Code に複数の重大な脆弱性を発見したと報告しました。細工されたリポジトリを開くだけで不正なコマンドが実行される恐れがあり、AI 開発ツールの信頼モデルに一石を投じる内容です。

何が起きたのか

Claude Code には Hooks（ツール実行前後にシェルコマンドを自動実行する仕組み）、MCP サーバー（外部ツール連携）、環境変数の読み込みといった設定機構があります。これらが悪用されることで、未信頼のディレクトリで Claude Code を起動した際に、任意のシェルコマンド実行や Anthropic API キーの流出が可能となることが判明しました。

つまり、攻撃者が悪意ある設定ファイルを仕込んだ Git リポジトリを用意し、開発者がそれを git clone して Claude Code を起動するだけで攻撃が成立します。

報告された脆弱性

CVE-2025-59536（CVSS 8.7 / High）— コードインジェクション

ツールの初期化時に自動実行を許すコードインジェクションの脆弱性です。Hooks や MCP サーバーの設定を悪用し、Claude Code が起動した瞬間に攻撃者のコマンドが実行されます。リモートコード実行（RCE）に直結する、最も深刻な問題です。

CVE-2026-21852（CVSS 5.3 / Medium）— 情報漏えい

プロジェクト読み込み時に環境変数の値が外部に漏洩する可能性がある脆弱性です。Anthropic API キーなどの機密情報が窃取されると、攻撃者がそのアカウントで API を不正利用できてしまいます。

その他の脆弱性

上記 2 件以外にも、同等の深刻度を持つ欠陥が確認されています。

なぜ危険なのか — 設定ファイルが攻撃経路になる

従来のセキュリティモデルでは「コードを実行しなければ安全」という前提がありました。しかし今回の脆弱性では、設定ファイル自体が攻撃経路となります。

設定機構	通常の用途	悪用方法
Hooks	ツール実行前後にシェルコマンドを自動実行	悪意あるコマンドを起動時に自動実行
MCP サーバー	外部ツールとの連携設定	偽サーバーを指定しデータを外部送信
環境変数	API キーなどの機密情報管理	設定ファイル経由で値を外部に流出

開発者が日常的に行う「リポジトリを clone して開発環境を立ち上げる」という行為自体がリスクになるという点で、VS Code の .vscode/ 設定を悪用する攻撃と同種のパターンです。ただし AI ツールはファイルシステムへの広範なアクセス権とシェルコマンドの実行権を持つため、影響はより深刻になりえます。

cmux — AIコーディングエージェント時代のターミナル紹介

Thu, 26 Feb 2026 00:00:00 +0000

cmux — AIコーディングエージェント時代のターミナル

cmux とは？

cmux は、AIコーディングエージェントとの並行作業に最適化された macOS ネイティブのターミナルアプリ です。Ghostty の描画エンジン (libghostty) をベースに、Swift + AppKit でゼロから構築されています。

Electron ではなくネイティブ実装なので、起動は高速、メモリ消費も少なく、GPU アクセラレーションによる滑らかな描画が特徴です。

“The terminal built for AI coding agents”

公式サイト: https://cmux.dev
GitHub: https://github.com/manaflow-ai/cmux (AGPL-3.0)

なぜ cmux が必要なのか？

Claude Code、Codex、Gemini CLI、Aider、Goose など、ターミナルベースの AI エージェントを日常的に使う開発者が増えています。しかし従来のターミナルや tmux では、複数のエージェントセッションを並行管理するのが大変でした。

「どのタブでどのエージェントが動いてるか分からない」
「エージェントが質問してるのに気づかなかった」
「開発サーバーの確認のためにブラウザとターミナルを行き来するのが面倒」

cmux はこれらの課題を解決するために設計されています。

主な機能

1. 縦タブ（バーティカルタブ）でワークスペースを一覧管理

左サイドバーに縦並びのタブが表示され、各ワークスペースの状態が一目で分かります：

Git ブランチ名
リンク済み PR のステータスと番号
作業ディレクトリ
リッスン中のポート番号
最新の通知テキスト

Firefox の縦タブに馴染みがある方なら、その便利さは想像がつくはず。タスクごとにワークスペースを作り、Cmd+1〜8 で瞬時に切り替えられます。

2. 通知リング — エージェントが注意を求めたら光る

AIエージェントが応答を待っている時、ペインに 青い通知リング が表示されます。サイドバーのタブにも未読バッジが付くので、複数エージェントを走らせていても「見逃し」がありません。

Cmd+Shift+U で最新の未読通知にジャンプ
Cmd+I で通知パネルを開いて一覧確認
OSC 9/99/777 エスケープシーケンスを自動検知
CLI からも送信可能: cmux notify --title "完了" --body "ビルド成功"

3. インアプリブラウザ — ターミナルの横にブラウザを並べる

WebKit ベースのブラウザがアプリ内に統合されています。ターミナルペインの隣にブラウザを分割表示して、開発サーバーのプレビューや PR の確認がワンストップで完結します。

Vibe Coding 2.0 — 「何を作らないか」を知る 18 のルール

Thu, 26 Feb 2026 00:00:00 +0000

Vibe Coding 2.0 — 「何を作らないか」を知る 18 のルール

Vibe Coding とは（前提知識）

Vibe Coding は、Andrej Karpathy（OpenAI 共同創設者）が 2025 年初頭に提唱した概念で、「コードの細部を手で書く」のではなく、AI に自然言語で指示してコードを生成させ、“ノリ（vibe）“で開発を進める スタイルを指します。Cursor や Claude Code などの AI コーディングツールの普及とともに広まりました。

MVP とは

MVP（Minimum Viable Product / 実用最小限の製品） とは、顧客に価値を提供できる最小限の機能だけを備えた製品のことです。完璧な製品を作り込んでからリリースするのではなく、核となる機能だけを素早く形にして市場に投入し、実際のユーザーからフィードバックを得ながら改善していくアプローチを指します。

目的: アイデアが市場に受け入れられるかを、最小のコストと時間で検証する
考え方: 「完成品」ではなく「検証のための道具」。100 点を目指すのではなく、60 点で出して学ぶ
例: 動画配信サービスなら、レコメンド機能や検索機能を後回しにして、まず「動画を再生できる」だけのアプリをリリースする

Vibe Coding 2.0 の文脈では、AI ツールを活用して MVP を高速にシップ（出荷）する ことが繰り返し強調されています。以下のルール群は、すべて「いかに早く MVP を世に出すか」を軸に設計されています。

Vibe Coding 2.0 とは

Harshil Tomar 氏が X で投稿した 「Vibe Coding 2.0: 18 Rules to be the Top 1% builder」 は、Vibe Coding の「次のフェーズ」を定義したものです。

コードレビューは CLAUDE.md / skills に書け — 同じ指摘を繰り返すな

Thu, 26 Feb 2026 00:00:00 +0000

コードレビューは CLAUDE.md / skills に書け — 同じ指摘を繰り返すな

基本情報

発表者: 戸塚翔太（Tech Lead / EM、スタートアップ開発責任者）
イベント: 「一歩踏み込む Claude Code 活用 LT 会」（Findy 主催、2026年2月22日）
スライド: Speaker Deck

問題提起

「人間に対してレビューするの、もうやめませんか？」

コードレビューにおいて以下のような無駄が繰り返されている:

問題	具体例
同じ指摘の繰り返し	変数名の命名規則、コーディングスタイルへの指摘が毎回発生
修正ラリー	「指摘修正しました」→ 再レビュー → 再指摘の往復
アーキテクチャ的な問題	根本的な設計の問題が PR 段階で発覚する

これらはレビュアーの時間を奪い、開発速度のボトルネックになっている。

解決策: 使い捨てコメントをナレッジに変える

核心のアイデアは 「レビューで出た指摘を、PR のコメントとして消費するのではなく、CLAUDE.md や skills に書き込んでナレッジとして蓄積する」 こと。

従来: レビュー指摘 → PR コメント → 修正 → 忘れられる → また同じ指摘
提案: レビュー指摘 → CLAUDE.md / skills に追記 → 以降 Claude が自動で遵守

CLAUDE.md に書くもの

コーディング規約（命名規則、ディレクトリ構成）
アーキテクチャ上のルール（「この層でこの処理はしない」等）
プロジェクト固有のパターン

skills に書くもの

レビュー観点をスキルとして定義
Claude Code が PR 作成前にセルフチェックできるようにする

自動化の仕組み

2 つの適用方法が紹介されている:

Claude Code + tmux で GitHub Issue/PR をウィンドウ単位で管理する tmux-focus スキル

Tue, 24 Feb 2026 00:00:00 +0000

name: tmux-focus description: “tmux ウィンドウの Issue/PR 切替: /tmux-focus [-w|-r] ”

tmux-focus スキル

現在の tmux ウィンドウの Issue/PR を切り替えるスキル。

使い方

`/tmux-focus <number>` — Issue モード

Bash で以下を実行:

1

~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh <number>

ウィンドウ名を issue-<number> に変更し、対応する GitHub Issue をブラウザで開く。

`/tmux-focus -w <number>` — PR worktree モード

gh pr view <number> で PR であることを確認する。PR でなければエラーメッセージを表示して終了。
Bash で以下を実行:
1

~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh --pr <number>
ウィンドウ名を pr-<number> に変更し、ブラウザで PR を開く。
EnterWorktree ツールで worktree を作成する。
worktree 内で以下を実行:
1

gh pr checkout <number>

`/tmux-focus -r <number>` — PR レビューモード

gh pr view <number> で PR であることを確認する。PR でなければエラーメッセージを表示して終了。
Bash で以下を実行:
1

~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh --pr <number>
ウィンドウ名を pr-<number> に変更し、ブラウザで PR を開く。
worktree 内でなければ EnterWorktree ツールで worktree を作成する。
worktree 内で以下を実行:
1

gh pr checkout <number>
PR のコード差分をレビュー開始する（gh pr diff <number> で差分を取得し、変更内容を分析）。

スクリプトが存在しない場合

~/.claude/skills/tmux-focus/scripts/tmux-issue-change.sh が存在しない場合は、以下の内容で作成して chmod +x する。

業務フローの設計にPowerPointではなくBPMNを使うべき理由 — Claude Code時代の詳細設計

Mon, 16 Feb 2026 00:00:00 +0000

業務フローの設計にPowerPointではなくBPMNを使うべき理由 — Claude Code時代の詳細設計

はじめに

業務システムの設計でSwim Lane（スイムレーン）形式の業務フローを書くとき、多くの現場ではPowerPointやFigmaが使われています。見た目は整えやすく、関係者への説明資料としてはよくできています。

しかし、この「人間が読むための図」を設計の源泉にしてしまうと、あと工程で大きなコストが発生します。特に、Claude CodeのようなAIエージェントを開発に活用する場合、設計成果物のフォーマット選択が開発効率を決定的に左右します。

本記事では、実際にPowerPointのスライドからBPMN 2.0に変換した経験をもとに、BPMNを採用する利点を解説します。

PowerPointの業務フローが抱える問題

PowerPointのスライドに描かれた業務フローは、本質的に「画像」です。

PowerPoint (.pptx)
├── 図形の座標とスタイル情報
├── テキストボックスの文字列
└── グループ化とレイヤー

これは人間が見るには十分ですが、次のような問題があります。

構造情報がない: 「この矢印がどのタスクからどのタスクへ向かっているか」をプログラムが読み取れない
アクターの定義が曖昧: レーンの境界が図形の配置で表現されているだけで、意味的な紐付けがない
分岐条件が自然言語: ゲートウェイの条件が図中のテキストに埋め込まれ、機械的に検証できない
フロー間の接続が不明確: 複数スライドにまたがるフローの接続点（「次のフローへ」）が視覚的な慣習に依存

BPMN 2.0とは

BPMN（Business Process Model and Notation） は、業務プロセスを図式化するための国際標準記法です。OMG（Object Management Group）が策定し、ISO 19510として国際標準化されています。現行バージョンはBPMN 2.0.2です。

BPMNの最大の特徴は、人間が理解できるフロー図と機械が処理できるXMLが一つのファイルに同居している点です。プールとレーン（Swim Lane）でアクターを表現し、タスク・ゲートウェイ・イベントでプロセスの流れを記述します。

BPMN 2.0がもたらす構造化

BPMN 2.0はXML形式で、見た目と意味の両方を持つフォーマットです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


<bpmn:process id="Process_1" isExecutable="false">
 <bpmn:laneSet id="LaneSet_1">
 <bpmn:lane id="Lane_reception" name="太平受付担当">
 <bpmn:flowNodeRef>r1</bpmn:flowNodeRef>
 <bpmn:flowNodeRef>r2</bpmn:flowNodeRef>
 </bpmn:lane>
 <bpmn:lane id="Lane_system" name="システム" />
 </bpmn:laneSet>

 <bpmn:task id="r1" name="修理内容の特定" />
 <bpmn:exclusiveGateway id="d2" name="保証範囲?" />
 <bpmn:sequenceFlow sourceRef="r1" targetRef="d2" />
</bpmn:process>

この構造から、以下がプログラム的に読み取れます。

Claude Code スキルで CloudWatch エラーレポートの Issue トリアージを自動化する

Thu, 12 Feb 2026 00:00:00 +0000

Claude Code スキルで CloudWatch エラーレポートの Issue トリアージを自動化する

背景

本番環境の ECS コンテナで発生したエラーは、CloudWatch Logs → Lambda → GitHub Issue という流れで自動起票される仕組みを運用しています。

タイトルは [prod][myapp] errors detected、ラベルは CloudWatchLog で統一されており、1つの Issue に複数のエラーブロックがまとまって届きます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


## Error Report - 2026-02-12 01:32:28 UTC

- **Environment**: prod
- **Log Group**: `/ecs/myapp-prod-ecs`
- **Error Blocks**: 3

### [1] 2026-02-12 01:32:26 UTC - `application`
（スタックトレース）

### [2] 2026-02-12 01:45:10 UTC - `application`
（スタックトレース）

### [3] 2026-02-12 02:01:33 UTC - `application`
（スタックトレース）

この Issue をそのまま放置すると、異なるエラーが混在したまま溜まっていきます。手作業で分類・個別 Issue 化するのは地味に面倒で、後回しにしがちでした。

iPhone から GitHub Issue を書くだけで Mac の Claude Code が自動実行される仕組みを作った — Self-hosted Runner + Claude Code CLI セットアップガイド

Wed, 11 Feb 2026 00:00:00 +0000

iPhone から GitHub Issue を書くだけで Mac の Claude Code が自動実行される仕組みを作った

TL;DR

GitHub Self-hosted Runner + Claude Code CLI を組み合わせて、iPhone で Issue を作成 → Mac 上の Claude Code が自動で調査・コード修正・PR 作成まで行う仕組みを構築した。2ステージ承認フロー付きで、/claude で調査、/approve で実行という安全な運用が可能。

モチベーション

普段 Mac の前にいないときでも、iPhone からコードの調査や修正を指示したい。GitHub Issue に書くだけで Claude Code が自動的に動いてくれれば、移動中でもコードレビューや修正依頼ができる。

完成した仕組み

iPhone GitHub Mac (self-hosted runner)
│ │ │
├─ Issue 作成 ────────────→│ │
│ (claude ラベル付与) │── ワークフロー起動 ─────→│
│ │ ├─ claude -p (読み取り専用)
│ │←── 調査結果コメント ──────┤
│ │ + 承認待ちラベル │
│ │ │
├─ /approve コメント ──────→│ │
│ │── ワークフロー起動 ─────→│
│ │ ├─ claude -p (書き込み許可)
│ │←── 実行結果 + PR ────────┤
│ │ - 承認待ちラベル │

トリガー一覧

操作	条件	動作
`claude` ラベル付き Issue 起票	起票者がリポジトリオーナー	Stage 1: 読み取り専用で調査
`/claude` コメント	コメント者がリポジトリオーナー	Stage 1: 読み取り専用で調査
`/claude --execute` コメント	コメント者がリポジトリオーナー	Stage 1 スキップ、直接実行
`/approve` コメント	コメント者がリポジトリオーナー + `承認待ち` ラベル	Stage 2: 計画に基づき実行

必要なもの

macOS マシン (Apple Silicon / Intel)
Claude Code CLI がインストール済み (npm install -g @anthropic-ai/claude-code)
Claude Max/Pro プラン (OAuth トークン) または Anthropic API キー
GitHub CLI (gh)

セットアップ手順

1. Self-hosted Runner のインストール

GitHub の個人アカウントでは Runner はリポジトリ単位の登録になる。同一マシンに複数の Runner を並置できる。

Ghostty + Claude Code 連携ガイド

Wed, 04 Feb 2026 00:00:00 +0000

Ghostty + Claude Code 連携ガイド

GhosttyとClaude Codeの組み合わせは、多くの開発者が推奨する構成です。主なポイントをまとめます。

すぐに使える機能

Shift+Enter がネイティブ対応

Ghosttyでは Shift+Enter による改行入力がそのまま動作します。他のターミナルでは /terminal-setup で設定が必要ですが、Ghosttyでは不要です。

GPU アクセラレーション

Claude Codeの出力が大量になっても、GPUレンダリングのおかげでスムーズにスクロール・表示されます。VS Codeのターミナルでは大量テキストのペースト時にフリーズすることがありますが、Ghosttyではその問題がありません。

Azure OpenAI

Wed, 16 Jul 2025 00:00:00 +0000

Azure OpenAI

- Azure OpenAI Service申請について

補助金助成金

Thu, 16 Jan 2025 00:00:00 +0000

補助金

Gradio

Mon, 30 Dec 2024 00:00:00 +0000

Gradio

scikit-learn: 異常検知

Thu, 12 Dec 2024 00:00:00 +0000

異常検知

sklearnを用いた異常検知のサンプルコード

sklearn（サイキットラーン）は、Pythonで機械学習を行うための強力なライブラリです。異常検知も、sklearnの様々なアルゴリズムを用いて行うことができます。

異常検知の手法選択

異常検知の手法は、データの種類や異常パターンによって異なります。代表的な手法としては、以下のものが挙げられます。

One-Class SVM: データの境界線を学習し、その境界から離れた点を異常と判定します。
Isolation Forest: データ点を孤立させるような決定木を複数作成し、異常度をスコア化します。
Local Outlier Factor (LOF): データ点の近傍の密度に基づいて異常度を計算します。

サンプルコード（Isolation Forest）

ここでは、Isolation Forestを用いた異常検知のサンプルコードをPythonで記述します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


from sklearn.ensemble import IsolationForest
import numpy as np

# サンプルデータ生成
np.random.seed(42)
X = np.random.randn(100, 2) # 正常データ
X = np.r_[X, np.random.randn(20, 2) + [3, 3]] # 異常データ

# Isolation Forestモデルの作成
clf = IsolationForest(contamination=0.2) # 異常データの割合を指定
clf.fit(X)

# 異常度の予測
y_pred = clf.predict(X)

# 異常データの抽出
anomalies = X[y_pred == -1]

# 結果の表示
print("異常データ:")
print(anomalies)

コード解説

データの生成: 正常なデータと異常なデータを生成します。
モデルの作成: IsolationForestのインスタンスを作成し、contaminationパラメータで異常データの割合を指定します。
モデルの学習: fitメソッドでモデルを学習させます。
異常度の予測: predictメソッドで各データの異常度を予測します。
異常データの抽出: 予測結果が-1のデータを異常データとして抽出します。

その他の注意点

contaminationパラメータ: 異常データの割合を事前にある程度把握している場合に、このパラメータを指定することで、より正確な異常検知が可能になります。
特徴量のスケーリング: 特徴量のスケールが異なる場合、標準化や正規化を行うことで、モデルの性能が向上する場合があります。
ハイパーパラメータのチューニング: Isolation Forestには、他にも様々なハイパーパラメータが存在します。GridSearchCVなどを用いて、最適なパラメータを探索することができます。

より詳細な情報

sklearnの公式ドキュメント: IsolationForestの詳しい説明や他の異常検知アルゴリズムについては、sklearnの公式ドキュメントを参照してください。
Qiitaなどの技術ブログ: 多くの技術ブログで、sklearnを用いた異常検知の具体的な事例や解説が紹介されています。

応用

異常検知は、不正検出、故障検知、品質管理など、様々な分野で活用されています。

LLM: ペルソナ

Thu, 07 Nov 2024 00:00:00 +0000

ペルソナ

生成 AI との融合で素早く深くペルソナを理解する！AI インタビューのご紹介

DSpy

Fri, 04 Oct 2024 00:00:00 +0000

DSPy (Declarative Sequencing for Python)

https://dspy-docs.vercel.app/ (Programming—not prompting—Language Models)

DSPyについて

DSPyは、LMプロンプトとウェイトをアルゴリズム的に最適化するためのフレームワークです、特にLMがパイプライン内で1回以上使用される場合。 LMを使用して複雑なシステムを構築するなし DSPy、あなたは一般的に次のことを行う必要があります:

(1)問題をステップに分解する、 (2)各ステップが個別にうまく機能するまでLMをうまく促す、 (3)ステップを微調整してうまく連携する、 (4)合成例を生成する各ステップを調整し、 (5)これらの例を使用して、より小さなLMを調整してコストを削減します。

現在、これは困難で厄介です。パイプライン、LM、またはデータを変更するたびに、すべてのプロンプト（または微調整手順）を変更する必要がある場合があります。

これをより体系的ではるかに強力にするために、 DSPy 2つのことを行います。まず、プログラムの流れを分離します(modules)各ステップのパラメーター（LMプロンプトとウェイト）から。第二に、 DSPy 新しい optimizers、これは、LMコールのプロンプトやウェイトを調整できるLM駆動アルゴリズムです。metric 最大化したい。

DSPy のような強力なモデルを日常的に教えることができます GPT-3.5 または GPT-4 と地元のモデル T5-base または Llama2-13b タスクではるかに信頼性が高くなること、つまり、より高い品質を持つこと、および/または特定の障害パターンを回避すること。 DSPy オプティマイザーは同じプログラム異なる各LMの指示、ショットの少ないプロンプト、および/またはウェイトの更新（finetunes）。これは、LMとそのプロンプトが、データから学習できるより大きなシステムの最適化可能な部分としてバックグラウンドにフェードインする新しいパラダイムです。 tldr; LMでハードタスクを解決するためのプロンプトが少なく、スコアが高く、より体系的なアプローチ。

ニューラルネットワークへのアナロジー

ニューラルネットワークを構築するときは、マニュアルを書きません for-loops 以上のリスト手調整フロート。代わりに、次のようなフレームワークを使用できます PyTorch レイヤーを作成する(例: Convolution または Dropout)0次に、オプティマイザー（SGDやAdamなど）を使用して、ネットワークのパラメーターを学習します。

同上！DSPy 適切な汎用モジュールを提供します（例: ChainOfThought、 ReAct等）、文字列ベースのプロンプトトリックを置き換えます。迅速なハッキングと1回限りの合成データジェネレーターを置き換えるには、 DSPy 一般的なオプティマイザーも提供します(BootstrapFewShotWithRandomSearch または MIPRO)、これはプログラムのパラメーターを更新するアルゴリズムです。コード、データ、アサーション、またはメトリックを変更するときはいつでも、コンパイルあなたのプログラムをもう一度 DSPy 変更に適合する新しい効果的なプロンプトを作成します。

Apple: App Store Connect

Tue, 03 Sep 2024 00:00:00 +0000

App Store Connect

スクリーンショットの仕様

アップデート

✓ Built IPA to build/ios/ipa (46.7MB) To upload to the App Store either: 1. Drag and drop the “build/ios/ipa/.ipa” bundle into the Apple Transporter macOS app https://apps.apple.com/us/app/transporter/id1450874784 2. Run “xcrun altool –upload-app –type ios -f build/ios/ipa/.ipa –apiKey your_api_key –apiIssuer your_issuer_id”. See “man altool” for details about how to authenticate with the App Store Connect API key.

xcrun altool での apiKey と apiIssuer の取得方法

xcrun altool を使用して App Store Connect にアプリをアップロードする際に、apiKey と apiIssuer の値が必要になりますね。これらの値は、App Store Connect で API キーを作成することで取得できます。

AWS: ECS: Fargate: pidMode

Mon, 02 Sep 2024 00:00:00 +0000

AWS ECS Fargate: pidMode

AWS FargateのpidModeは、タスク内のコンテナ間でプロセスID（PID）名前空間を共有するための設定です。これにより、同じタスク内のコンテナが互いのプロセス情報にアクセスできるようになります¹²。

例えば、モニタリング用のサイドカーコンテナが、他のコンテナのプロセス情報を取得して監視することが可能になります。FargateではpidMode=taskのみがサポートされており、これを有効にすると、タスク内のすべてのコンテナが同じPID名前空間を共有します²。

この機能は、特にセキュリティや監視の観点から便利で、プロセスの監視やシステムコールのトラッキングが容易になります¹。

ソース: Copilot との会話、 2024/9/2 (1) 【アップデート】ECS on Fargateでサイドカーからプロセス …. https://dev.classmethod.jp/articles/ecs-on-fargate-support-shared-pid-namespace/. (2) AWS Fargate がプロセス ID 名前空間の共有とカーネルパラメータ …. https://aws.amazon.com/jp/about-aws/whats-new/2023/08/aws-fargate-pid-namespace-sharing-kernel-configuration/. (3) [ECS/Fargate] [request]: Support pidMode: task on Fargate #676. https://github.com/aws/containers-roadmap/issues/676. (4) 【アップデート】ECS on FargateがsystemControlsをサポートし …. https://dev.classmethod.jp/articles/ecs-on-fargate-support-systemcontrols/. (5) Amazon ECS on AWS Fargate - Datadog Infrastructure and …. https://docs.datadoghq.com/integrations/ecs_fargate/.

pidModeを指定しなくてもサイドカー構成を取ることは可能です。pidModeは、特定のユースケースでプロセスID名前空間を共有するためのオプションですが、サイドカーコンテナ自体は他の方法で連携できます。

例えば、サイドカーコンテナは以下のような方法で他のコンテナと連携します：

ネットワーク共有: 同じタスク内のコンテナはデフォルトで同じネットワーク名前空間を共有するため、互いに通信できます。
ボリューム共有: データを共有するために、同じボリュームをマウントすることができます。
環境変数や設定ファイル: コンテナ間で設定情報を共有するために使用できます。

これらの方法を組み合わせることで、pidModeを使用しなくても効果的なサイドカー構成を実現できます。

記事

Vercel

Mon, 02 Sep 2024 00:00:00 +0000

Vercel

v0

https://v0.dev/

v0とは？

Vercel v0は、最新のフロントエンド開発プラットフォームで、特に開発者の効率を最大化することを目指しています。以下のような特徴があります¹²：

リアルタイムコラボレーション：開発チームがリアルタイムで共同作業できる機能を提供します。
自動スケーリング：需要に応じてリソースを自動的に調整し、効率的なリソース管理を実現します。
統合された開発環境：開発者が最小限の設定で最大限の成果を得られるように設計されています。
テキストプロンプトからのUI生成：自然言語での指示を基に、ウェブサイトのユーザーインターフェース（UI）を自動生成します。
リアルタイムプレビュー：コードの変更が即座に反映され、フィードバックサイクルを短縮します。

これにより、プロジェクトの立ち上げからデプロイまでのプロセスが大幅に簡素化され、開発者はより迅速に市場に製品を投入することが可能となります¹²。

何か特定の機能について詳しく知りたいことがありますか？

ソース: Copilot との会話、 2024/9/2 (1) Vercel v0とは何か：最新技術の概要とその背景について …. https://www.issoh.co.jp/tech/details/3416/. (2) 【2024最新】v0 by Vercelとは？特徴や使い方、料金まで解説 …. https://ai-gallery.jp/tools/v0-by-vercel/. (3) 【Claude Artifactに匹敵！？】Vercel v0の使い方と活用事例20 …. https://bing.com/search?q=vercel+v0+%e3%81%a8%e3%81%af. (4) 【生成AI】Vercel v0の登録方法〜料金プランまで解説 …. https://funrepeat.com/fr-note/3547. (5) [Vercel] v0 Private Betaの試用レポート - Zenn. https://zenn.dev/shimarisu_121/articles/b2aabc4f0110d7. (6) undefined. https://t.co/v5wvCdhPov.

記事

vercelのv0(ブイゼロ)を試してみた (今後はAIソリューション使い倒し、どのような場面でどのソリューションが効果的で、どうプロンプトすれば良いのかマスターになった方が差別化になる)
いま流行りのvercelの【v0】の自作アイデア17選✨

AWS

はい、Vercelの基盤システムはAWS上で運用されています。Vercelは、AWSのインフラを利用して、グローバルにスケール可能なフロントエンドコードのデプロイとトラフィックのルーティングを行っています³。

他に何か知りたいことがあれば教えてくださいね。

ソース: Copilot との会話、 2024/9/2 (1) AWS + Vercel. https://vercel.com/partners/aws. (2) データ活用基盤を作ってみたその1(構成シナリオ) #AWS - Qiita. https://qiita.com/kamein/items/81df29ef9d32bf0a0810. (3) Vercelを調査していて感じたメリット・デメリット - Zenn. https://zenn.dev/smartcamp/articles/9d9b4224be862f.

Django

VercelにDjangoをデプロイする

Figma

Tue, 20 Aug 2024 00:00:00 +0000

オートレイアウト

FigmaのREST APIで取得したJSONデータから、FrameがAuto Layoutかどうかを判断するには、以下のフィールドをチェックします：

layoutMode: このフィールドが存在し、値が "HORIZONTAL" または "VERTICAL" であれば、そのFrameはAuto Layoutが適用されています。

例えば、以下のようなJSON構造です：

1
2
3
4
5
6
7


{
 "id": "123",
 "name": "Frame 1",
 "type": "FRAME",
 "layoutMode": "HORIZONTAL",
 ...
}

この例では、layoutModeが "HORIZONTAL" なので、このFrameはAuto Layoutが適用されています。

ソース: Copilot との会話、 2024/9/19 (1) Figma オートレイアウトの使い方とうまくできないときの … - Designup. https://designup.jp/figma-auto-layout.html. (2) 【Figma】オートレイアウトの使い方完全ガイド（Auto Layout …. https://tagnote.net/figma/auto-layout/. (3) 【Figma】フレームの使い方マスター編〜グループとの違いや …. https://implist.dev/entries/figma-frame-and-auto-layout-group. (4) Working with Auto Layout in Figma - a Self-Guided Tutorial. https://www.figma.com/community/file/1207414800398401244/working-with-auto-layout-in-figma-a-self-guided-tutorial. (5) FrameNode | Plugin API - Figma. https://www.figma.com/plugin-docs/api/FrameNode/.

ColPali

Thu, 01 Aug 2024 00:00:00 +0000

ColPali

arXiv

アーカイブ

記事

PGVector

Wed, 31 Jul 2024 00:00:00 +0000

PGVector

ニューラルネットワークの知識の蒸留 distilling the knowledge in a neural networkPGVector (Postgres)
Rails/PostgreSQL/pgvector を組み合わせてベクトル検索をする。
https://github.com/yassun/sample-pgvector
https://hub.docker.com/r/pgvector/pgvector
https://github.com/pgvector/pgvector-python
LangChain と pgvector(Postgres)を用いて関連性の高いドキュメントを手軽に検索する
生成 AI でテキスト分類やってみた

SentenceTransformer

知識蒸留

MUSE

Muse: Text-To-Image Generation via Masked Generative Transformers を読んだメモ

Google Gemini

Fri, 17 May 2024 00:00:00 +0000

Google Gemini

旧 Bard
Google AI Studio からアクセス

モデル

Gemini Ultra
Gemini Pro
Gemini Nano

トークン

Gemini (1M), Claude3(200k), GPT4(128K)

マルチモーダル

テキスト
ビデオ
音声
画像
ファイル
フォルダー

Gemini Business

Google Workplace + 20USD/月
Gemini Ultra が利用可能
入力データが学習に使われないことが保証されている

Gemini Enterprise

Google Workspace + 30USD/月

個人

Gemini

無料

Gemini Advanced

Google One AI プレミアム (2,900 JPY/月)
2TB ストレージ

記事

Snowflake: Cortex

Sun, 14 Apr 2024 00:00:00 +0000

Snowflake Cortex

Snowflake: Snowpark

Sun, 14 Apr 2024 00:00:00 +0000

Snowflake: Snowpark

Apache Spark

今さら聞けない Python - Spark のご紹介

GetAI: RAG

Fri, 12 Apr 2024 00:00:00 +0000

RAG

【勉強メモ】RAG But Better: Cohere AI によるリランカー　 RAG But Better: Rerankers with Cohere AI

Faiss

Fri, 15 Mar 2024 00:00:00 +0000

Faiss (Facebook AI Similarity Search)

LangChain

Fri, 15 Mar 2024 00:00:00 +0000

LangChain

生成 AI アプリ開発フレームワーク LangChain 入門

独自データの活用:

ファインチューニング (LLM + 独自データ -(再レーニング)-> 独自 LLM)
プロンプトエンジニアリング(独自データをコンテキストとして与えて LLM から生成)
ベクトル検索(ベクトル化された独自データから最適解をコンテキストとして与えて LLM から生成)

LangChain とは

大規模言語モデル（LLM）を使用したアプリケーション開発のためのオープンソース・オーケストレーション・フレームワーク
チャットボットや仮想エージェントなどの LLM 駆動型アプリケーションの構築プロセスを簡素化

LangChain の仕組みとは

抽象化によって LLM アプリケーションのプログラミングを効率化する開発環境
1 つ以上の複雑なプロセスの構成ステップをすべてカプセル化した名前付きコンポーネントとみなすことでコードを簡素化

言語モデルのインポート:

ほぼすべての LLM を使用できます

プロンプトテンプレート:

プロンプト: LLM に与えられる指示
プロンプトエンジニアリング:LLM が入力を解釈し、最も役立つ方法で出力を構成するために必要なコンテキストを効果的に提供するプロンプトを作成する作業

チェーン:

LLM を他のコンポーネントと組み合わせ、一連の関数を実行することでアプリケーションを作成
LLMChain: 基本チェーン: 単にモデルを呼び出し、そのモデルのプロンプトテンプレートを呼び出す

インデックス:

トレーニングデータセットに含まれていない特定の外部データソース

AWS: Bedrock: KnowlegeBase

Thu, 14 Mar 2024 00:00:00 +0000

AWS: Bedrock: Knowlege Base

AWS: Pinpoint

Mon, 04 Mar 2024 00:00:00 +0000

AWS Pinpoint

Amazon Pinpoint を AWS エキスパートが解説 😎 AWS でマーケティングを簡単・手早く効率化させましょう 🚀

Push:

SMS:

Amazon Pinpoint を使った SMS 送信をおこなってみた
Amazon SNS や Amazon Pinpoint からのモバイルテキストメッセージ (SMS) にかかる料金が予想よりも高くなるのはなぜですか?
Send transactional SMS via Amazon PinPoint

Notification:

通知

FCM:

Firebase Cloud Messaging

SNS:

ChatGPT: PowerPoint生成

Wed, 21 Feb 2024 00:00:00 +0000

CHatGPT PowerPoint 生成

ChatGPT: SQL 生成

Thu, 15 Feb 2024 00:00:00 +0000

ChatGPT SQL 生成

https://github.com/ademakdogan/ChatSQL

AWS: Kendra

Tue, 13 Feb 2024 00:00:00 +0000

AWS: Kendra

Video:

生成AI: RAG

Mon, 12 Feb 2024 00:00:00 +0000

RAG(検索拡張生成)

大規模な言語モデルの出力を最適化するプロセスです。
応答を生成する前に、トレーニングデータソース以外の信頼できる知識ベースを参照します。
大規模言語モデル (LLM) は、膨大な量のデータに基づいてトレーニングされ、何十億ものパラメーターを使用して、質問への回答、言語の翻訳、文章の完成などのタスクのためのオリジナルの出力を生成します。
LLM の既に強力な機能を、モデルを再トレーニングすることなく、特定の分野や組織の内部ナレッジベースに拡張します。
LLM のアウトプットを改善するための費用対効果の高いアプローチであるため、さまざまな状況で関連性、正確性、有用性を維持できます。
外部ソースから取得した情報を用いて、生成 AI モデルの精度と信頼性を向上させるテクノロジです。

基盤モデル(FM)

基盤モデルとは何ですか?

例:

BERT
GPT(OpenAI)
Titan(Amazon)
Jurassic(AI21)
Claude(Anthropic)
Cohere
Stable Diffusion
BLOOM
Hugging Face

Bedlock

Amazon Bedrock 使ってみた
Amazon SageMaker は機械学習の包括的なライフサイクル（構築、訓練、展開）をサポートする
Bedrock は Fine-tuning は出来るものの基本的には Amazon Titan や AI スタートアップの基盤モデル（FM）を API から利用することに重きを置いています。
自分たちで最初から構築したモデルでなければビジネスとして成り立たないシーンでは、Amazon Bedrock を選択してはいけません。
非常に厳しいセキュリティ要件がある場合にも避けた方が良い

生成AI: エンべディング

Mon, 12 Feb 2024 00:00:00 +0000

エンベディング

Embedding（エンベディング）の概念を理解してみた
単語や文といった自然言語の情報を、その単語や文の意味を表現するベクトル空間に配置することです。
単語の埋め込み(Word embedding)

埋め込み (数学)

数学的構造間の構造を保つような単射のこと
あるルールのもとで、ユニークな入力に対してユニークがアウトプットがえられる

word2vec

https://ja.wikipedia.org/wiki/Word2vec

AWS: Bedrock: GenAI

Tue, 06 Feb 2024 00:00:00 +0000

AWS: Bedrock: GenAI

Amazon Bedrock とは【速報】AWS の生成 AI サービスである Amazon Bedrock がリリースされたので朝イチで触ってみた Amazon Bedrock “Claude 2” と、ChatGPT “GPT-4” を比較してみる AWS による生成 AI の新サービス「Amazon Bedrock」の可能性を考察する Amazon Bedrock でモデルごとに画像を生成してみた Bedrock のはじめかた Amazon Bedrock の導入効果をレビューでご紹介（KDDI アジャイル開発センター株式会社-みのるん） Build generative AI chatbots using prompt engineering with Amazon Redshift and Amazon Bedrock GPT 連携アプリ開発時の必須知識、RAG をゼロから解説する。概要＆Python コード例 Amazon Bedrock の Knowledge base で簡単に RAG を構築

Github:

API:

Boto3: https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/bedrock.html

モデル

Titan FMs
Claude 2
Jurassic-2 (Python SDK)
Stable Diffusion

Claude 2

Jurassi-2

日本語対応していない
AWS の"推しの AI" 「Jurassic-2」を使ってみた！！Bedrock ローンチ前に使えるんやん！

生成AI（ジェネレーティブAI）

Fri, 02 Feb 2024 00:00:00 +0000

生成 AI（ジェネレーティブ AI/GenAI）

プログラミングコード生成 AI

GitHub Copilot
Amazon CodeWhisperer

BigQuery

Amazon Redshift/Amazon Q generative SQL

Amazon Bedrock

PingCAP/TiDB

Azure

Fabric

Snowflake

Morph

ECS: aws-cli

Sun, 07 Jan 2024 00:00:00 +0000

ECS: aws-cli

curl, unzip は入っていること

 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


ARG BASE_IMAGE=myimage-cicd-appbase
ARG TAG=latest

FROM ${BASE_IMAGE}:${TAG} as server

ARG USERNAME=ubuntu
ARG GROUPNAME=ubuntu
ARG PASSWORD=ubuntu
ARG UID=1000
ARG GID=1000

ENV APP_BASE=/usr/src/app \
 LIB_BASE=/usr/src/lib \
 POETRY_VERSION=1.0.10 \
 PATH="/root/.poetry/bin:$PATH"

RUN mkdir -p /var/run/gunicorn && mkdir -p /storage
RUN apt-get update && apt-get install -y sudo

RUN groupadd -g ${GID} ${GROUPNAME} && \
 useradd -m -s /bin/bash -u ${UID} -g ${GID} -G sudo ${USERNAME} --home-dir ${APP_BASE} && \
 echo ${USERNAME}:${PASSWORD} | chpasswd && \
 echo "${USERNAME} ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers

# aws-cli
RUN curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
RUN unzip awscliv2.zip
RUN sudo ./aws/install

# Application
COPY . ${APP_BASE}
WORKDIR ${APP_BASE}

RUN pip install pip poetry urllib3==1.26.15 -U && \
 poetry config virtualenvs.create false && \
 poetry install && pip install urllib3==1.26.15 pyOpenSSL -U

RUN chown -R ${USERNAME}:${GROUPNAME} ${APP_BASE}
RUN chmod 777 /run/gunicorn
USER ${USERNAME}

CMD ["/usr/src/app/docker/codebuild/entry_web.sh", "/usr/src/app"]

PyCaret

Mon, 25 Dec 2023 00:00:00 +0000

PyCaret: AutoML

azure cognitive service

Thu, 29 Jun 2023 00:00:00 +0000

Azure Cognitive Services

Azure Cognitive Services は、Microsoft Azure の製品として提供されている AI 機能作成サービスです ¹². これらのサービスは、REST API およびクライアントライブラリ SDK を使用して、人工知能を直接的に利用することなく、アプリケーションに認識、言語理解、音声、画像、検索などの機能を追加することができます ¹³.

Azure Cognitive Services は、視覚、音声、言語、決定、検索などの分野を対象に AI 機能を簡単に利用することができます ¹. また、学習済みの AI モデル予測機能を活用できるのが特徴です ¹.

ソース: Bing との会話 2023/6/30

(1) AI をもっと身近に！Azure Cognitive Services とは？今注目されて …. https://www.rworks.jp/cloud/azure/azure-column/azure-entry/28078/.
(2) Azure Cognitive Services とは - Azure Cognitive Services. https://learn.microsoft.com/ja-jp/azure/cognitive-services/what-are-cognitive-services.
(3) Cognitive Services - AI ソリューション向け API | Microsoft Azure. https://azure.microsoft.com/ja-jp/products/cognitive-services/.

AWS Windows

Tue, 20 Jun 2023 00:00:00 +0000

AWS EC2 Windows

AWS Connect CCP

Mon, 08 May 2023 00:00:00 +0000

AWS Connect: CCP(Contact Control Panel)

Contact Control Panel とは、Amazon Connect 問い合わせコントロールパネル (CCP) を使用して問い合わせと通信するための GUI の機能です ²。エージェントが CCP にアクセスし、問い合わせを処理できるようになる前に、行わなければならない操作がいくつかあります ³。

ご参考になれば幸いです。

ソース: Bing との会話 2023/5/8

(1) 問い合わせコントロールパネルへのアクセスを提供する - Amazon …. https://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/amazon-connect-contact-control-panel.html.
(2) Provide access to the Contact Control Panel - Amazon Connect. https://docs.aws.amazon.com/connect/latest/adminguide/amazon-connect-contact-control-panel.html.
(3) 【Amazon Connect】在宅コールセンター向けに CCP（発着信 …. https://qiita.com/duplicate1984/items/3a4d93a2e9bb5fcf54d1.

資料:

Amazon Connect とは？導入前に知っておきたい機能・料金・注意点と事例

Google ログイン

AWS Connect に Google ユーザーを紐付けることは可能です。ただし、紐付ける前に、AWS Cognito 単体で、ユーザ ID のサインアップ（ユーザ登録）・サインイン（ログイン）ができるようにする必要があります ³。

また、外部で認証されたユーザー（ID フェデレーション）へのアクセス権限を付与することもできます ¹。

ご参考になれば幸いです。

ソース: Bing との会話 2023/5/8

AI/LLM on hdknr blog

Gemini Agentモード：Google Workspaceを丸ごと自動化するAIエージェントの実力

Gemma 4 31B vs Qwen3.5-27B — ローカルLLM最強はどちらか

Gemma 4がAPI経済を破壊する — オープンモデルがSaaS課金モデルを変える理由

Microsoft BitNet完全オープンソース化：GPUなしで1000億パラメータLLMをCPUで動かす時代へ

Gemma 4 31Bの脱獄モデル「CRACK」登場 — Abliteration技術でセーフティを除去

AutoAgent — AIがAIを育てる自己改善エージェントOSSライブラリ

claw-code-local — Claude Code風のAIコーディングエージェントをローカルLLMで動かす

Karpathy の LLM Wiki — AIエージェントが育てる個人ナレッジベースという新パターン

Anthropic Conway とは — 24時間稼働する常駐型AIエージェントの全貌

Claude Code 開発で機能が静かにデグレードする — 出力品質テストで防ぐ方法

LLMで株式投資戦略を自動生成 — 松尾研のフィードバック設計実験が示す「モデル選択」の重要性

Onyx（旧 Danswer）完全ガイド — 無料で使えるオープンソース AI プラットフォーム

AI UGC動画広告ツール徹底比較 — Arcads・Creatify・HeyGen・Synthesia の選び方

4ツールの概要

Arcads — UGC広告のリアルさで圧倒

Creatify — URL貼り付けで動画を自動生成

HeyGen — 企業向け多言語動画の王者

Synthesia — 業界最古参、エンタープライズの標準

Arcads 完全ガイド — AIで UGC 動画広告を大量生成するプラットフォーム

Arcads とは

会社の概要

主要機能

AIアクターライブラリ

カスタムAIアバター

感情・表現コントロール

バッチ生成

多言語対応

Claude Code のコンテキスト圧縮戦略 — ソースコードから見える5つのアプローチ

AI Brain Fry: AIの使いすぎで脳が焼ける現象とその対策

Claude Code + Self-hosted Runner: 「Auto mode is unavailable for your plan」エラーの原因と対処

症状

原因

1. OAuth トークンの期限切れ（副次的問題）

2. Opus の auto mode 制限（真の原因）

Claude Code の sensitive file チェックを回避する — git worktree の配置場所を .claude/ の外に移す

問題：.claude/ 配下は sensitive file 扱い

背景：ブログ記事作成の自動化ワークフロー

Claude Code を Ollama でローカル無料実行する方法

MiroFish その後: 3週間で GitHub Star 4.7万超へ — コミュニティの広がりと今後の展望

「toA」時代の到来 — AIエージェント向けサービス200超が示す新市場の全体像

なぜ「toA」が生まれたのか

エージェントの「5つの生存条件」

枯れた領域に次々と新種が生まれている

メール — AgentMail

記憶 — Mem0

Webブラウジング — Agent Maps

外部ツール連携 — Composio

「稼ぐエージェント」と「使うエージェント」

toAの「エッジ」がプラットフォームになる

まとめ

AI社員40人を作って1ヶ月で全部やめた話 — 壊れない設計のために知っておくべきこと

Claude AI で投資銀行レベルの財務モデルを作成する 12 のプロンプト

Claude Code + Celery: LLMが決定論的処理を動的に委譲するオーケストレーション

Claude Codeベストプラクティス疲れに終止符 — claude-code-best-practiceリポジトリ一本で運用する方法

ベストプラクティス疲れという問題

claude-code-best-practiceリポジトリとは

導入手順

Step 1: リポジトリをクローン

Step 2: Claude Codeにプロジェクト固有のベストプラクティスを提案させる

startup hookで常に最新化する

Mistral Voxtral TTS: ElevenLabs に匹敵するオープンウェイト音声AI

「値は計算されていた。ただ届いていなかっただけ」— LLMエージェントプロンプトのハードコード問題

Anthropic の3エージェント・ハーネス設計: Claude が6時間でフルアプリを自律構築する仕組み

OpenClaw で YouTube 運用を全自動化? 「月1000万円」の主張を技術的に検証する

元の主張の要約

OpenClaw とは

技術的に「できること」と「できないこと」

OpenClaw で実現可能な部分

現状では難しい部分

Prompt Engineering から Harness Engineering へ: AI エンジニアリングの進化と「仕組みの設計力」の時代

AI疲れへのアンサー: Claude Code のハーネス機能は本当に必要か

Claude Code で Laravel→Django 全自動移行をやってみた（1/3）計画編

Claude Code で Laravel→Django 全自動移行をやってみた（2/3）自動化基盤編

Claude Code で Laravel→Django 全自動移行をやってみた（3/3）実行結果・教訓編

Claude Code の Auto Mode から見える AGI への道筋

Dexter: 約200行で動く自律型金融リサーチエージェント

Claude Code: dangerously-skip-permissions をやめて auto mode に移行する

Claude Codeで「専門家チーム」を構築する：カスタムエージェントとCoworkの活用法

NotebookLM と Claude Code の発想の違い

問題：`.claude/` 配下は sensitive file 扱い

方法1: カスタムエージェント（`.claude/agents/`）