Claude Code や Cursor で開発していると、.env に書いた API キーを AI が普通にファイルシステムから読みに行く。.gitignore していても関係ない。この課題に対して、1Password が Anthropic・Cursor・GitHub・Vercel・Perplexity と連携し「AI エージェント時代のシークレット管理」を本気で構築し始めた。 何が発表されたのか 2026年3月17日、1Password は 1Password Unified Access を発表した。人間・マシン・AI エージェントにまたがるアクセスを一元的に発見・保護・監査するためのプラットフォームだ。 従来のパスワードマネージャーの枠を超え、AI エージェントが本番環境で実際に動作する時代に合わせたクレデンシャル管理を提供する。 なぜ必要なのか：.env 問題 AI コーディングツール（Claude Code、Cursor など）は、タスク遂行のためにローカルファイルシステム上のファイルを読む。.env ファイルに平文で保存された API キーやトークンは、AI エージェントから直接アクセスできてしまう。 .gitignore はリポジトリへのコミットを防ぐだけで、ローカルファイルシステム上での読み取りは防げない。つまり、現状の .env ベースのシークレット管理は AI エージェント時代には不十分だ。 各社との連携内容 Anthropic（Claude Code / Cowork / ブラウザ拡張） Anthropic は 1Password を統合し、Claude Code、Cowork、Claude ブラウザ拡張からボールト内のアイテムを安全にオートフィルできるようにする。ユーザーの同意のもと、Claude がサイトやサービスに 1Password から直接クレデンシャルを取得してログインできる仕組みだ。 Cursor（Hooks による just-in-time シークレット） Cursor との連携では、Cursor Hooks を活用した just-in-time なシークレット提供を実現する。 仕組みは以下の通り: プロジェクトに hooks.json を設定 Cursor がシェルコマンドを実行する前に、1Password Environments Hook Script が起動 プロセスがアクセスを要求すると、1Password がユーザーに認証を求める 承認されると、必要なシークレットがランタイムセッションのメモリ上にのみ提供される これにより、平文キーがディスクやソースコードにコミットされることがなく、環境変数のハードコードやトークンの履歴残留も防げる。 ...

SAP を置き換えるのは現実的ではない——だからこそ、工夫しながら SAP を使い続ける方法を考える必要があります。a16z が公開した「Why the World Still Runs on SAP」というレポートを受けて、Kurashiru CTO の Masato Otake 氏が自社での業務 AI 開発の知見を交えてまとめた考察を紹介します。 ERPとは何か ERP は単なるソフトウェアではありません。企業が何十年もかけて蓄積してきた業務ルール、承認フロー、例外処理の集合体です。組織の暗黙知がカスタムコードとして蓄積されており、長年稼働し続けています。 System of Record として、受発注・在庫・会計・人事まで、あらゆる業務の「正」のデータが ERP に集約されています。長年にわたって積み重ねられた業務ルールと例外処理は、まさに企業の制度的記憶そのものです。 もしリプレイスしようとしたら、数年単位の時間と億単位のコストがかかるでしょう。サンクコストがあまりにも大きいため、顧客側にリプレイスのニーズが強くないことが多い。 一方で、複雑化しすぎた ERP はアジリティ高く変更することが難しくなっています。何十年分のカスタマイズが積み重なり、一箇所を変えると別の業務に影響が出る。AI のような最先端を取り入れようにも、変更コストが高すぎてスピードについていけない状況です。 アクションレイヤーの登場 ここに機会があります。ERP そのものを置き換えるのではなく、その上を覆う「アクションレイヤー」を構築することです。 System of Action、Action Layer、Agent Layer など呼び方はいろいろありますが、要するに System of Record の上に被さって業務フローを自動化するレイヤー のことです。 ERP はデータの正として残り続けます。変わるのは、ユーザーが業務を行うインターフェースです。アクションレイヤーが ERP とユーザーの間に入り、操作を抽象化し、ワークフローを制御する。ERP に手を入れることなく、その上で業務ロジックの追加や変更を柔軟に行えるようになります。 これにより： ERP 自体は安定した System of Record として維持しつつ ビジネス環境の変化にはアクションレイヤー側でアジリティ高く対応できる AI のような新しい技術も、ERP の改修なしにアクションレイヤーに組み込めるため、変更リスクとスピードのトレードオフを、レイヤーを分けることで解消する考え方です。 アクションレイヤーがもたらす2つの変化 1. ERPの操作をラップして使いやすくする ERP の画面は複雑で、トランザクションコードや入力フィールドの知識が求められます。アクションレイヤーがこれを抽象化し、意図ベースの操作に変換することで： ユーザーは ERP の画面構成を覚える必要がなくなる オンボーディングコストや引き継ぎコストが大きく削減される 2. 複数システムを横断するオートメーション 「請求書の差異が3%を超えたら説明文を作成し承認にルーティング」のようなイベント駆動型の自動化は、SAP だけ、Salesforce だけでは実現できない、もしくは工数が大きすぎます。アクションレイヤーがシステム横断の制御を接着することで可能になる領域です。 ...

AIコーディングエージェント向けの開発フレームワーク「superpowers」（obra/superpowers）がGitHubで9万スターを超え、世界中のAI開発者から注目を集めている。Claude Code・Cursor・Codex・OpenCode・Gemini CLIなど主要なAIエージェントに対応した、再利用可能な「スキル」コンポーネントで構成されるワークフローだ。 「AIに思いつき実装をさせない」という設計哲学 superpowersの根底にある考え方はシンプルだ。AIに自由に実装させるのではなく、明確な仕様とプロセスでエージェントを制御する。この思想が7段階ワークフロー全体に貫かれている。 7段階ワークフロー superpowersは以下の7つのフェーズで開発を進める: ステップ フェーズ 内容 1 Brainstorming 対話で要件を詰める 2 Git Worktree 隔離環境で並列開発 3 Write Plan 2〜5分単位のタスクに分割 4 Execute サブエージェント駆動で実装 5 TDD RED → GREEN → REFACTOR 6 Code Review 仕様適合性＋品質の2段階チェック 7 Branch Complete マージまたはPR作成 TDDがAIエージェントに効く理由 TDD（テスト駆動開発）はAIエージェントとの協働において特に威力を発揮する。 レッドテストを先に書く = AIへの仕様の明示化 「何を作るべきか」をテストで定義してからエージェントに渡すことで、エージェントが目標を見失わない。ゴールが曖昧なままエージェントを走らせるのと比べて、実装精度が段違いに向上する。 ❌ 曖昧な指示: 「ユーザー認証機能を実装して」 ✅ TDDアプローチ: まずテストを書き、通過条件を明示してから実装させる Git Worktreeで並列開発 Git Worktreeを活用することで、自分がメインブランチで作業しながら、AIが別の隔離環境で並行して開発を進められる。 長時間の自律タスクほど恩恵が大きい コンフリクトのリスクを最小化しながら並列作業が可能 タスク粒度の設計 計画フェーズ（Write Plan）でタスクを 2〜5分サイズ に分割するのがポイントだ。細かく分割することでAIのコンテキスト肥大化を防ぎ、品質を維持できる。 こんな人に向いている ハーネス（開発基盤）を自作する時間がない人 AI駆動開発の型を学びたい初心者 既存のワークフローを体系化したい人 導入方法 作者はJesse Vincent（歴戦のOSSベテラン）。 Claude Code: 公式マーケットプレイスから導入可能 Codex / OpenCode: 手動セットアップが必要 「スキル」という再利用可能なコンポーネントで構成されているため、自分のプロジェクトに必要な部分だけを取り込むことも可能だ。 ...

社内資料をRAGで検索しているのに「欲しい情報に限って見つけてくれない」「関係ない文書ばかり読んで的外れな回答をする」という経験はないでしょうか。AIDB が紹介する新しいRAG手法は、検索方法そのものをモデル自身に判断させるというアプローチで、この問題に正面から取り組んでいます。 従来RAGの限界：一本調子の検索 従来のRAGはシンプルです。あらかじめ決まった方法（主にベクトル類似度検索）で文書チャンクを引っ張ってきて、まとめてLLMに渡す。検索がハズれたら、その時点でもう正解にはたどり着けません。 どんなに優れたモデルを使っても、読む資料がズレていれば回答の質は上がりません。問題は「LLMの能力」ではなく「検索戦略の固定化」にあります。 3つの検索戦略を状況に応じて使い分ける この新手法では、モデルが以下の3つの検索戦略から最適なものを選択し、必要に応じて組み合わせます。 検索戦略 特徴 向いているケース キーワード検索 特定の語句・コードをピンポイントで探す 固有名詞、型番、コマンドなどを調べるとき 意味検索（セマンティック検索） 意味的に近い文書を探す 概念的な質問、言い換えが多い文書を扱うとき チャンク全文読み 対象範囲を丸ごと読み込む 文脈が重要な長文、前後関係が必要なとき 重要なのは、どの順番で、どの検索を使うかをモデル自身が推論して決定する点です。固定のパイプラインではなく、質問の性質や文書の構造に合わせて動的に戦略を切り替えます。 なぜこれが機能するのか 読み込むテキスト量は同等以下 従来のRAGと比較して、読み込むテキストの量は同等かそれ以下です。にもかかわらず、回答精度は大きく向上します。これはトークン数の節約にもつながります。 モデル進化と共にスケールする構造 この手法の特筆すべき点はモデルの推論能力と性能が比例することです。モデルの推論能力が高いほど、「どの検索を、どの順番で使うか」という判断精度が上がり、RAG全体の性能が向上します。 つまり、将来より優れたモデルが登場すれば、RAGのフレームワーク自体を改修しなくても自然に性能が底上げされます。 実装への示唆 この手法を自社のRAGシステムに取り入れる場合、以下の点が設計のポイントになります。 1. 検索ツールの整備 モデルが選択できるよう、複数の検索エンドポイントを用意する必要があります。BM25（キーワード）、ベクトルDB（意味）、ドキュメント取得（全文）の3種を揃えるのが基本構成です。 2. ツール呼び出し（Function Calling）の活用 OpenAI / Anthropic / Google などの主要LLMはFunction Callingをサポートしています。検索戦略の選択をFunction Callingで実装することで、モデルが自律的に検索を制御できます。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 tools = [ { "name": "keyword_search", "description": "固有名詞・型番・コマンドなど特定のキーワードで文書を検索する", "parameters": {"query": "string"} }, { "name": "semantic_search", "description": "意味・概念の近さで関連文書を検索する", "parameters": {"query": "string"} }, { "name": "read_document", "description": "指定した文書チャンクを全文読み込む", "parameters": {"document_id": "string"} } ] 3. 推論能力の高いモデルを選ぶ ...

AIエージェントを複数並列で動かせば効率が上がる——そう思っていないだろうか。実は、「ダラダラと1つのエージェントと長時間向き合う」方が、最終的に良い成果を出せるかもしれない。K.Ishi氏（@K_Ishi_AI）がX（旧Twitter）で提唱した、AI時代の新しい働き方の視点を紹介する。 並列実行は本当に効率的か？ AIエージェントを2つ同時に走らせれば効率は2倍、3つなら3倍——直感的にはそう思える。しかし現実はそうならない。 ボトルネックは 人間の脳 にある。 人間の脳はタスクを切り替えるたびに「切り替えコスト（スイッチングオーバーヘッド）」が発生する。エージェントAの結果を確認している最中にエージェントBが返答を返してくる。Bに意識を向けた瞬間、Aの文脈が薄れる。Aに戻ると、また状況を思い出すところからやり直しになる。 この繰り返しが積み重なると： 同時実行するエージェント数が増えるほど、1つあたりの注意力が低下する 脳が疲弊し、集中力が落ちる 思考の質が悪化し、「浅い判断」が増える 浅い判断が生む大きな手戻り 表面的な処理速度は上がっても、判断の質が下がれば意味がない。 1つのエージェントにじっくり向き合っていれば気づけたはずのミスを見逃す。そのミスが後になって発覚し、大規模な手戻りが発生する——このリスクが、並列実行では増大する。 並列実行の「速さ」は、手戻りコストを考慮すると、実は遅くなっている可能性がある。 「ダラダラ長時間働く」という逆張り戦略 では、どうすれば良いのか。K.Ishi氏が提案するのは、シンプルな逆張りだ。 AIの実行ログをボーっと眺め、脳のエネルギーを温存し、AIに任せた仕事の分だけ楽になれば良い。そして、楽になった分だけちょっと長く働いた方が、案外最終的には並列実行よりも良質な成果を出すかもしれない。 つまり： エージェントは1つに絞る — 並列実行を避け、1つのエージェントの出力に集中する ログをゆっくり眺める — 急いで判断せず、じっくりと結果を吟味する 脳のエネルギーを温存する — タスク切り替えをなくし、深い思考力を保つ 楽になった分、少し長く働く — 集中力を維持しながら、より長い時間作業する この結果、「浅くて速い」並列作業より、「深くて丁寧な」直列作業の方が最終的な成果の質が高くなる可能性がある。 AI時代の「集中」の価値 AIの登場で「何タスクを並列でこなせるか」が生産性の指標になりつつある。しかし、タスクの数ではなく タスクの質 を追求する視点も重要だ。 AI時代において、人間に求められる価値が「AIの高速な実行を監督・統制する判断力」にシフトしていくとすれば、その判断力を最大化するために「集中」に投資することは理にかなっている。 並列実行を前提としたワークフロー設計が主流になる中、あえて「1エージェント集中型」のワークスタイルを選択するという議論がもっと盛り上がっても良いのかもしれない。 まとめ 項目 並列実行型 集中型（直列） 処理速度 速い 遅い 脳への負担 大きい 小さい 判断の質 浅くなりがち 深く保てる 手戻りリスク 高い 低い 最終的な成果の質 場合による 安定して高い AIエージェントが増えた時代だからこそ、「どう使うか」だけでなく「何個使うか」「どのくらい並列にするか」を意識的に設計することが重要になってくる。あなたのAI活用スタイルは、並列型か集中型か、どちらが合っているだろうか。 元ツイート: K.Ishi (@K_Ishi_AI) — X, 2026-03-17

AI ツールを活用し、UGC（User Generated Content）スタイルの広告クリエイティブを量産する手法が注目されている。Instagram 上で A/B テストを回し、データドリブンで勝ちパターンを見つけて売上につなげるワークフローだ。従来は実際のクリエイターに依頼していた UGC 動画を、AI アバターと音声合成で低コスト・大量に生成できるようになった。 ワークフローの全体像 この仕組みは大きく 4 つのステップで構成される。 ステップ 1: クリエイティブ会議（週1回） 週に 1 回のクリエイティブ会議で「どんな切り口・構成で作るか」を決める。ここで重要なのは、テストすべき変数を明確にすることだ。 冒頭の掴み（フック）のバリエーション 話す人物の見た目（年齢層、雰囲気） 動画の長さ（15秒 / 30秒 / 60秒） 訴求ポイント（価格、品質、体験談など） ステップ 2: AI ツールでバッチ量産（毎日 4〜5 時間） 会議で決めた方針に沿って、AI ツールを組み合わせて機械的にクリエイティブを量産する。主に使われるツールは以下の通り。 ツール 役割 特徴 Creatify UGC 動画生成 商品 URL を入力するだけでスクリプト・動画を自動生成。1,500 以上の AI アバターに対応 HeyGen AI アバター動画 500 以上のストックアバターと 140 以上の言語をサポート。リアルな表情と口の動きが特徴 ElevenLabs 音声合成 70 以上の言語に対応した高品質ナレーション生成。感情やトーンの調整が可能 CapCut 動画編集 テロップ追加、BGM、テンプレート適用などの仕上げ作業に使用 Creatify の場合、商品の URL を貼り付けるだけで 5〜10 パターンの UGC スタイル動画を自動生成できる。HeyGen では ElevenLabs の音声と組み合わせることで、より自然な口の動きと音声の仕上がりになる。 ...

Anthropic が Claude 専用の認定資格試験を公開した。AWS の SAA（Solutions Architect Associate）や GCP の Professional Cloud Architect に相当する位置づけで、「AI アーキテクト」としてのスキルを公式に証明できる資格だ。 試験の概要 この認定試験は、単なるチャットの使い方を問うものではなく、本番環境で Claude を使ったシステムを設計・構築できるかを評価する本格的な内容となっている。 試験で問われる主なトピックは次のとおり: エージェントアーキテクチャ設計 — マルチエージェント構成や状態管理の設計力 Claude Code 設定 & ワークフロー — 開発環境への組み込みと自動化フロー プロンプトエンジニアリング — 精度・信頼性を高めるプロンプト設計 ツール設計 & MCP 統合 — Model Context Protocol を活用した外部ツール連携 コンテキスト管理 & 信頼性 — 長いコンテキストの扱い方や出力の安定性確保 試験形式は 60 問・120 分のオンライン監視試験。 無料の準備コース Anthropic Academy では 13 本以上の準備コースが公開されており、すべて無料で受講できる。認定取得のための学習コストは基本的にかからない。 なぜ今、この資格が重要なのか 「Claude が使えます」は今誰でも言える。 「Certified Architect です」は証明になる。 生成 AI ツールの普及が進む中、「AI が使える」というスキルの差別化が難しくなってきている。Anthropic の認定資格は、その差別化を公式に示す手段となる。 採用・案件獲得の場面で、早い段階で認定を持っているかどうかが差になる時代が来ると予想されている。 まとめ 項目 内容 認定名 Claude AI Certification（AI アーキテクト） 形式 60 問・120 分・オンライン監視試験 準備コース Anthropic Academy（13 本以上、無料） 試験範囲 エージェント設計、Claude Code、プロンプト、MCP、コンテキスト管理 Claude を業務や開発で活用しているエンジニアにとって、スキルを公式に証明できる貴重な機会だ。Anthropic Academy のコースを活用して早めに準備を進めておきたい。 ...

AWS Japan AI チームが「draw.io の図解自動生成」フレームワークを arXiv 論文にまとめた。論文名は GenAI-DrawIO-Creator（arXiv 2601.05162、2026年1月）。実装は GitHub で公開され、GitHub Trending の2位まで到達した。 概要 自然言語のテキストを入力すると、draw.io で使える XML 形式のダイアグラムを自動生成するフレームワーク。バックエンドには Claude 3.7 を Amazon Bedrock 経由で使用している。 評価結果 指標 結果 初回セマンティック精度 94% フィードバック後の精度 100% 平均生成時間 7.4 秒（手動比約 5 倍速） 「7.4秒で図が生成される」体験が当たり前になる日が近づいている。 仕組み フレームワークの処理フローは以下のとおり: 自然言語入力: ユーザーがテキストでダイアグラムの内容を説明する LLM による XML 変換: Claude 3.7 が自然言語を draw.io XML 形式に変換する フィードバックループ: 生成結果を評価し、精度が不十分な場合は自動で再生成する draw.io への出力: 生成した XML を draw.io で開いてそのまま使用できる GitHub 公開と反響 実装は DayuanJiang/next-ai-draw-io として GitHub で公開されており、公開直後に GitHub Trending の2位まで到達した。 ...

はじめに 2026年から、Anthropic が「Claude Certified Architect」という公式資格の提供を開始しました。これは Claude の実務活用能力を認定する初めての公式資格であり、AI エンジニアやアーキテクトにとって注目の認定制度です。 本記事では、Claude Certified Architect 試験の概要や対策方法について解説します。 Claude Certified Architect とは 「Claude Certified Architect」は、Anthropic が提供する Claude の実務活用能力を認定する公式資格です。Claude を使ったシステム設計・アーキテクチャ構築の能力を評価します。 対象者 Claude API を活用したシステムを設計・開発するエンジニア AI を組み込んだプロダクトを企画・設計するアーキテクト 企業内で Claude 活用を推進するリーダー・コンサルタント 試験の特徴 Anthropic 公式認定の資格 Claude の実務活用能力（設計・実装・運用）を総合的に評価 AI アーキテクチャ設計のベストプラクティスへの理解が問われる 試験範囲（想定） Claude Certified Architect 試験では、以下のような領域が出題範囲として想定されます。 1. Claude API の活用 Messages API の基本的な使い方 プロンプト設計（System Prompt、Human/Assistant ターン） ストリーミングレスポンスの実装 ツール使用（Tool Use / Function Calling） 2. アーキテクチャ設計 Claude を組み込んだシステムの設計パターン RAG（Retrieval-Augmented Generation）アーキテクチャ マルチエージェントシステムの設計 Claude とその他のサービス（データベース、外部 API）の連携 3. セキュリティとコンプライアンス プロンプトインジェクション対策 機密情報の取り扱いと出力フィルタリング 利用規約・ポリシーへの準拠 4. パフォーマンスと最適化 レイテンシ・コスト最適化 プロンプトキャッシング（Prompt Caching）の活用 バッチ処理と非同期処理の設計 5. モニタリングと運用 Claude を使ったシステムのモニタリング エラーハンドリングとリトライ設計 ログ収集・分析によるシステム改善 学習リソース 試験対策に活用できる公式リソースを紹介します。 ...

Anthropic で Claude Code を開発している Thariq が、社内での大規模なスキル活用から得た知見をまとめたノートが公開された。スキルは Claude Code の最も使われる拡張ポイントの一つであり、柔軟で作りやすく配布もしやすい。しかしその柔軟性ゆえに「何が正解か」を判断しにくいという問題もある。本記事はそのノートの内容を日本語でまとめたものだ。 スキルとは何か スキルは「ただの Markdown ファイル」という誤解が多いが、実際にはスクリプト・アセット・データなどを含むフォルダー全体がスキルだ。Claude Code では動的なフックの登録など多彩な設定オプションも提供されている。 最も面白いスキルは、こうした設定オプションやフォルダー構造をクリエイティブに活用しているものだ。 スキルの 9 つのカテゴリ 社内のスキルを棚卸ししたところ、いくつかのカテゴリに分類できた。最も優れたスキルは一つのカテゴリに綺麗に収まる。自組織でどのカテゴリが欠けているかを確認するのに役立つ。 1. ライブラリ・API リファレンス ライブラリ、CLI、SDK の正しい使い方を説明するスキル。内部ライブラリや Claude Code が苦手とする一般的なライブラリを対象にする。参照コードスニペットのフォルダーや、Claude が避けるべき「落とし穴（gotchas）」リストを含めることが多い。 例: billing-lib — 社内課金ライブラリのエッジケースや注意点 internal-platform-cli — 社内 CLI の全サブコマンドと使用例 frontend-design — 自社デザインシステムに Claude を合わせる 2. プロダクト検証 コードが正しく動作しているかをテスト・検証するスキル。Playwright や tmux などの外部ツールと組み合わせることが多い。検証スキルは Claude のアウトプットの正確性を担保するために極めて有用で、エンジニアが 1 週間かけて磨き上げる価値がある。 出力の動画録画や各ステップでのプログラムによるアサーションなどの手法も有効だ。 例: signup-flow-driver — サインアップ → メール確認 → オンボーディングをヘッドレスブラウザで実行 checkout-verifier — Stripe テストカードでチェックアウト UI を操作し、請求書の状態を確認 tmux-cli-driver — TTY が必要なインタラクティブ CLI テスト用 3. データ取得・分析 データ・監視スタックに接続するスキル。認証情報付きでデータを取得するライブラリ、特定のダッシュボード ID、一般的なワークフローの手順などを含む。 ...