AI/LLM

2026年5月5日、マイアミのスタートアップ Subquadratic が、業界に衝撃を与える新LLM「SubQ」を発表した。キャッチコピーは「Claude Opus超え」。1200万トークンのコンテキスト長、競合比1,000倍のコンピュート削減、1/5以下のコスト——数字だけ見れば夢のような話だ。しかし果たして実態はどうなのか、技術的な仕組みから現時点の課題まで整理する。 SubQとは何か SubQは、Subquadratic Sparse Attention（SSA） と呼ばれる新しいアテンション機構を採用したLLMだ。開発したのはフロリダ州マイアミ拠点のスタートアップ「Subquadratic」で、CEOはJustin Dangel（5回連続起業家）、CTOはAlexander Whedon（元Meta、元TribeAI生成AI部門長）。 2017年のTransformer論文以来、すべての主要LLMはアテンション計算のコストがコンテキスト長の2乗に比例するという「二次スケーリング問題」を抱えてきた。長いコンテキストを扱おうとすると、RAGによるチャンク化・ベクトルDB検索・要約ループといった「誤魔化し」が必要になる理由がここにある。SubQはこの根本問題を解決したと主張している。 Subquadratic Sparse Attention（SSA）の仕組み 従来の密なアテンション（Dense Attention）では、あるトークンが他のすべてのトークンと比較される。コンテキスト長Nに対してコストはO(N²)となり、Nが大きくなるほど指数的に重くなる。 SSAはこれを根本から変える。各クエリトークンに対して、実際に重要な位置だけを選択し、その部分集合についてのみアテンション計算を行う仕組みだ。 標準Transformer: 全N個のトークンを全N個と比較 → コストO(N²) SSA: クエリごとに重要な位置k個を選択してアテンション計算 → O(N×k) kがNに対して十分小さければ → 実質O(N)（線形スケーリング） DeepSeekなどの既存スパースアテンション手法との違いも強調されている。DeepSeekのアプローチはアテンション計算のインデックス構築自体に二次コストが残るのに対し、SSAはその構築コストも線形に抑える設計だという。ただし詳細な技術仕様は非公開のため、この主張は現時点で独立検証できない。 主な性能指標 Subquadraticが公表している数値は以下のとおり。なお、これらはすべて同社による自社計測であり、独立検証は未実施である点に留意が必要だ。 指標 SubQ 比較対象 コンテキスト長（本番API） 100万トークン Claude Opus 4.7: 100万 コンテキスト長（研究用） 1200万トークン Opus 4.7の12倍 速度（1Mトークン時） FlashAttention比 52倍高速 — スループット 150 tokens/秒 — コスト（1Mトークン処理） 約$8 最先端モデル: 約$2,600 コンピュート削減（12Mトークン） 競合比 約1,000倍削減 — コスト面では「Claude Opusの約1/5」と説明されており、長文コンテキスト処理において経済的に圧倒的な優位性を主張している。 ベンチマーク結果 長文コンテキスト評価として注目されているのが MRCR v2（Multi-needle Retrieval and Context Reasoning）だ。複数の情報を長いコンテキストから正確に取り出す能力を測るベンチマークで、長文処理の実力差が出やすい。 ...

AIを使ったソフトウェア開発が急速に普及する中、「バイブコーディング」と「エージェンティックエンジニアリング」という2つのアプローチの境界線が曖昧になりつつある。Simon Willisonがこの問題を鋭く考察した記事が話題を呼んでいる。 バイブコーディングとエージェンティックエンジニアリングとは AI開発の文脈で、2種類のアプローチが対比されることが多い。 バイブコーディング（Vibe Coding） コードを深く読み込まず、AIの出力をそのまま使う開発スタイル。主に個人プロジェクトや試作品向けとされてきた。コードの内容を理解しなくても動くものが作れる、いわば「感覚」で進める手法だ。 エージェンティックエンジニアリング（Agentic Engineering） AIを強力なツールとして活用しつつ、プロのエンジニアが責任を持ってコードをレビューし、本番環境に耐えうるシステムを構築するアプローチ。品質・セキュリティ・保守性への意識が高い。 以前は「バイブコーディング＝個人・試作」「エージェンティックエンジニアリング＝本番」と明確に区別できた。しかし、AIの性能向上により、その境界線が揺らいでいる。 「もうコードを一行ずつ読まなくなった」という告白 Simon Willisonは自身の経験として、本番向けのコードでさえ、AIが書いたものを一行ずつレビューしなくなってきていると率直に認めている。 Willisonはこう述べる。Claude Codeに「JSON APIエンドポイントを作って」と頼めば、正しく実装してくれる——それはもう分かっている、と。 これは、大企業で別チームが開発した機能を、中身をほとんど確認せずそのまま使う感覚に近い。AIをある種のブラックボックスとして扱い始めているということを意味する。 人間のチームとの違いは「責任」にある。別チームの開発物には担当者がいて、問題が起きれば責任を取る人間が存在する。しかしAIには責任を取る能力がない。この非対称性が、Willisonに居心地の悪さを感じさせる根本的な理由だ。 AIの信頼が油断を生む 問題はさらに深い。AIが問題なくコードを書き続けることで「このAIは信頼できる」という過信が生まれる。そしていつか、本当は慎重であるべき場面でAIを過信して失敗するリスクが高まっていく。 また、AIの普及でソフトウェアの品質評価基準そのものも変化している。 従来: 充実したテストスイート、丁寧なドキュメント → 高品質の証明 現在: AIを使えばテストもドキュメントも数十分で完璧に揃えられる 見た目の完成度はもはや品質の指標にならない。代わりに価値を持ち始めたのは「実際に誰かが数週間・数ヶ月にわたって日常的に使っている」という実績だ。 開発プロセスの重心がシフトする @iwashi86 の整理によれば、AIによってコーディング速度が10倍（Willlison の元記事では「1日200行→2000行」）に跳ね上がったことで、従来のソフトウェア開発プロセス全体に変化が生じている。 コードを書くコストが劇的に下がったことで、失敗を恐れずに大胆なアーキテクチャ変更や仕様変更を試せるようになった。以前は実装コストが高すぎて試せなかったアイデアを、気軽にプロトタイプできる環境が整いつつある。 これはボトルネックを「実装」から「設計・判断・文脈理解」へとシフトさせることを意味する。 ソフトウェアエンジニアという職業の未来 Willisonは、AIが自動でコードを書く時代になってもソフトウェアエンジニアという職業は脅かされないと考えている。 その理由はシンプルだ：ソフトウェア開発はそもそも非常に困難な作業だから。AIはプロのエンジニアが持つ経験・判断力・文脈理解を増幅する道具にすぎない。AIを使いこなすためにこそ、深い専門知識が必要になる。 そして最終的には、企業も個人も「素人がAIで自作したシステム」より「プロがAIを駆使して作り上げた、実績のある製品」に対してお金を払いたいはずだ、とWillisonは結論づける。 まとめ Simon Willisonの考察は、AI開発ツールの急速な進化がエンジニアの「当たり前」を静かに書き換えていることを示唆している。 バイブコーディングとエージェンティックエンジニアリングの境界は、AIの性能向上とともに溶けつつある AIへの依存は「責任の所在」という根本的な問題を内包している ソフトウェアの品質指標は「見た目の完成度」から「実績・継続使用」へ移行しつつある 開発ボトルネックは「実装」から「設計・判断」へシフトしている それでもプロのエンジニアの価値はなくならない — AIはあくまで増幅器だ 元記事: Vibe Coding and Agentic Engineering Are Getting Closer Than I’d Like ツイート: @iwashi86

Anthropic のエンジニアとされる人物が Claude Code を使って Polymarket（予測市場プラットフォーム）向けの取引 bot を構築し、$200（約3万円）を $14,300（約200万円）に成長させたという事例が話題を集めている。ただし本人の公的な確認は取れておらず、複数の紹介ツイートも「伝えられるところによると」という留保を付けている点は注意が必要だ。 単純に取引回数を増やすのではなく、「勝てる場面だけを選ぶ」判断を AI に委ねるという設計思想が注目ポイントだ。 Polymarket とは Polymarket は分散型の予測市場プラットフォームで、政治・経済・スポーツなど様々なイベントの結果に対してポジションを取れる。各イベントの結果確率を市場参加者が売買することで価格が形成される仕組みになっている。 bot のアーキテクチャ このシステムは Claude Code をベースに、以下の3つの機能を組み合わせて動作する。 1. 大規模な取引データ分析 8,600万件の取引データを AI で分析 過去のパターンから「どういう取引が利益を出しやすいか」を学習 2. ウォレットランキング Polymarket の 14,000 以上のウォレットを数分でスキャン 各ウォレットの勝率・利益率を算出し、ランキング化 高勝率ウォレット（クジラ）が動いたタイミングを検出する 3. 厳選した取引実行 1日あたりわずか 10 回のみ取引を実行 勝率の高いクジラが動いた相乗りポジション、かつクジラより早く Exit（手仕舞い） 高確率の取引だけに絞ることでドローダウンを最小化 設計思想：「勝てる場面だけ選ぶ」 このシステムが興味深いのは、取引頻度ではなく取引品質を最大化している点だ。 多くのアルゴリズムトレードは「できるだけ多くの機会を捉える」方向に走りがちだが、このボットは逆の方針を選んでいる。 力技で数をこなす → 採用しない 「勝てる場面だけ選ぶ」判断を AI に任せる → 採用 1日10回という制約は、シグナルの質を落とさないための意図的な設計といえる。 Claude Code + Skills + MCP の連携 このような bot を実際に構築するには、Claude Code 単体ではなく、Skills や MCP（Model Context Protocol） を組み合わせた拡張が必要になる。Claude Code だけでは外部 API への接続や大規模データパイプラインを扱いきれないためだ。 ...

2026年Q1、Anthropicは3ヶ月間で120以上の機能をリリースした。これは18時間に1機能というペースであり、エンジニア1人あたり1日約5PRというアウトプットが確認されている。 なぜこれが可能なのか。@suthio_ による note記事「Anthropicの異次元の開発速度を支える7つの要因」が、その構造を詳細に分析している。@MLBear2 がX上で紹介し大きな注目を集めた内容を、本記事でまとめる。 7つの要因 1. AIがAIを作る再帰構造 Anthropic全社のコードベースの70〜90%はClaudeが書いており、Claude Code製品自体では約90%に達するとされる。ツールの改善がツール改善速度を加速させる自己強化ループが成立している。 このフライホイール構造により、「AIを使ってAIを改善する」サイクルが止まらない。開発速度は線形でなく、指数的に加速し続ける。 2. 未公開モデルへの先行アクセス Anthropicの社員は、公開前のモデル（Claude Mythosなど次世代モデル）をコスト制約なしで利用できる。これは世界中の開発者より数ヶ月先の能力を使って開発を進められることを意味する。 競合他社がAnthropicの公開済みモデルに合わせて開発している間、Anthropic自身はさらに数段階先のモデルで作業している。この非対称性は構造的な優位性を生む。 3. PRD廃止・プロトタイプ主義 仕様書（PRD）を書かない。代わりに、1機能あたり10〜20個のプロトタイプを数時間で作成し、実装したものを全社員に使わせてフィードバックを得る。 「考えてから作る」のではなく「作ってから考える」。このプロセスで、机上の設計では気づけないUX上の問題を早期に発見できる。 4. PMの仕事の変容 従来のPM（プロダクトマネージャー）の役割は「要件を定義する人」だった。Anthropicでは「大量のプロトタイプを評価する人」へと変わっている。 著者は「デザインプロセスは死んだ」という表現を使うほど、この転換は根本的なものだと指摘する。PMに求められるスキルセットは、仕様書を書く能力から、良いプロトタイプを見極めるセンスへとシフトしている。 5. 全員Builder文化 PM、デザイナー、法務担当まで、全員がAIツールを使ってコードに触れる。部門間の「人から人への引き継ぎ」がほぼ消滅した。 従来のソフトウェア開発では、PM→デザイン→エンジニアリング→QAというハンドオフが必ず存在し、そのたびに情報の欠落と時間のロスが生まれていた。全員がBuilderになることで、このボトルネックが根本から消える。 6. 1人で複数AIを並行操作 エンジニアが5〜10個のClaudeインスタンスを同時に動かし、役割分担させながら作業する。従来の「実装者」から「オーケストレーター」へという役割の変化だ。 Claude Codeの開発者であるBoris Cherny氏は1日20〜30件のPRを生成するという。業界標準が週1〜2件であることを考えると、桁違いのアウトプットになる。 7. 超高速フィードバックループ コードを変更すると、即座に社内全員が利用できる状態に自動デプロイされる。本番に近い環境でのフィードバックを数時間単位で得られるサイクルが確立されている。 「リリースが怖い」文化は存在しない。小さく素早く動かし続けることが前提となっている。 7つは独立していない——相互強化の構造 著者の重要な指摘は、これら7つが「独立した施策のリスト」ではないという点だ。 AIがコードを書くから、プロトタイプを大量に作れる 大量のプロトタイプが作れるから、PRDが不要になる 全員がBuilderになれるから、ハンドオフがなくなる 未公開モデルを使えるから、数ヶ月先の能力で開発できる これら7つは互いに強化し合うシステムであり、「一部だけ真似する」と効果が限定的になる。構造ごと変える必要がある、というのが著者の結論だ。 他の組織が今すぐ始められる3つの原則 もっとも、Anthropicのすべてを真似することは現実的ではない。未公開モデルへのアクセスや、AIがAIを作る再帰構造は、Anthropicならではの特権的な条件だ。 著者は「規模や業種を問わず始められる」として、次の3つを挙げている。 プロトタイプ・ファースト思考 — 仕様書を書く前に動くものを作る 自分たちで使い倒す（内部ドッグフーディング） — 作ったものを開発者自身が日常的に使う 全員がBuilderを目指す — 非エンジニアもAIツールでコードに触れる環境を作る これらはツールや予算の問題ではなく、思想と文化の問題であり、今日から変えられる。 セキュリティ領域での実績 記事内では、Claude Code SecurityやProject Glasswingといった取り組みにも触れている。AIを使って数十年間潜んでいたバグを検出した事例が紹介されており、「大量のコードを読んで異常を見つける」タイプのタスクではAIが人間を圧倒しつつあることが示されている。 まとめ Anthropicの開発速度の源泉は、単なる「AIツールの活用」ではない。AIが組織の全層に浸透し、相互に強化し合うシステムとして機能していることにある。 「なぜこんなに速いのか」という問いの答えは、7つの個別の施策ではなく、それらが織りなす構造にある。そして、その構造の一端は、どんな組織でも今日から取り入れ始めることができる。 参考リンク 元記事: Anthropicの異次元の開発速度を支える7つの要因（@suthio_） 紹介ツイート: @MLBear2 on X

中国在住のあるユーザーが、Claude Code を「従業員」として使い、数十の Instagram アカウントを 24 時間体制で自動管理することで月 3 万ドル超を稼いでいるという事例が SNS で注目を集めている。AI を使った収益化が「すでにゲームのルール」になりつつある現状を、この事例から読み解く。 Claude Code による Instagram 自動管理で月 3 万ドル超 AI インフルエンス・オペレーターを名乗る @Jouhatsu_ai が X（旧 Twitter）で紹介したこの事例では、Claude Code が以下の作業を自律的にこなしている。 数十の Instagram アカウントを 24 時間運用: 投稿スケジュール管理、コンテンツ生成、エンゲージメント対応 トレンドリサーチを常時実施: バズっている数百のアカウントを継続的にモニタリングし、流行を把握 退屈な反復作業を全自動化: ユーザー本人は実務から解放され、戦略立案やチェックに集中できる 本人は「AI にすべての面倒な作業を任せ、自分は一日中のんびりできる」と話しており、Claude Code が文字通り自律エージェントとして機能している様子が伝わる。 英語圏では月 1.5 万〜4.2 万ドルの受託案件も @Jouhatsu_ai の引用ツイートによれば、英語圏の Claude Code ヘビーユーザーはこうした AI 自動化システムを構築・運用することで、クライアントから 月 1 万 5,500〜4 万 2,000 ドル を請求しているという。 さらに「Anthropic がこのやり方を 30 分の公式コンテンツでほぼすべて説明している」とも言及しており、公式ドキュメントや事例を参照すれば再現性のある手法として学べることを示唆している。 Claude Code が自律エージェントとして機能する理由 Claude Code がこうした自動化ビジネスに適している背景には、いくつかの技術的特性がある。 長期タスクの継続実行 Claude Code はコマンドラインから起動し、ファイル操作・Web 検索・API 呼び出しなどを連続して実行できる。単発の質問応答に留まらず、複数ステップにわたる業務フローを自律的にこなす。 ...

Claude Code を使い続けると、トークン消費が積み重なってコストが気になってくる。X（旧 Twitter）ユーザーの @xiaoying_eth が、トークン消費を最大90%削減できる10のGitHubリポジトリをまとめて紹介している。本記事では出力フィルタリング・シンボル単位参照・プロンプト制御・MCP サーバーという4アプローチで各ツールを分類し、導入しやすいものから解説する。 1. RTK (Rust Token Killer) リポジトリ: rtk-ai/rtk コンテキストに流れ込む前にターミナル出力をフィルタリングするツール。よく使う開発コマンド（cargo build、npm test など）の冗長な出力を削減することで、60〜90% のトークン削減を実現する。Rust 製のため高速で、Claude Code の実際のコーディングセッションでの効果が大きい。 詳細は「RTK（Rust Token Killer）で Claude Code のトークン使用量を60〜90%削減する」を参照。 2. Context Mode リポジトリ: mksglu/context-mode Playwright や GitHub のツール出力を SQLite に転送し、クリーンな要約のみを Claude に送信するアプローチ。生のツール出力をそのままコンテキストに流さないことで 98% の削減を達成している。ブラウザ自動化や CI/CD 連携を多用するワークフローに特に有効。 3. code-review-graph リポジトリ: tirth8205/code-review-graph Tree-sitter を使ってローカルでコードリポジトリをナレッジグラフに変換するツール。ファイル全体を渡す代わりにグラフ構造で必要な情報だけを抽出するため、大型モノリポでは 49倍 のトークン削減が可能。コードレビューや依存関係の調査に向いている。 4. Token Savior リポジトリ: Mibayy/token-savior MCP サーバーとして動作し、ファイル全体ではなくシンボル単位（関数・クラス・変数）でコードを参照するツール。コードナビゲーション操作で 97% のトークン削減を達成。外部依存がゼロなので導入しやすい。 5. Caveman Claude リポジトリ: JuliusBrussee/caveman “原始人の口調” で Claude に話させることで出力トークンを削減するユニークなアプローチ。技術的な正確性は維持しつつ、出力を 65〜75% 削減できる。プロンプトエンジニアリングによる出力スタイルの制御という発想が面白い。 詳細は「Claude を「原始人」口調にするとトークンが 80% 減る話」を参照。 ...

MacBook Pro M4 ローカルで Llama 3.3 70B を 11 時間動かし続け、機内でクライアント仕事をすべて片付けた開発者がいる。Wi-Fi 代 25 ドルを払わず、オフラインだけで完結させた「オフライン AI ワークフロー」の実例が話題になっている。 構成：ハードウェアとソフトウェア 使用機材はシンプルだ。 項目 内容 マシン MacBook Pro M4、64 GB 統合メモリ モデル Llama 3.3 70B（bf16 精度） 推論エンジン llama.cpp（localhost:8080 で待機） 生成速度 71 トークン/秒 コンテキスト長 約 60,000 トークン メモリ使用量 48.6 GiB（ほぼ上限） 離陸時バッテリー残量 3 時間 21 分 離陸前に書いたオーケストレーション・スクリプト キモはフライト前に仕込んだシステムプロンプトとスクリプトだ。要約すると以下のとおりだった。 1 2 3 4 5 6 7 8 あなたは今、MacBook 上のオフライン・オーケストレーターです。ネットはありません。 使えるのはローカルファイルと localhost:8080 の Llama 推論サービスだけです。 バッテリーは 3 時間強。 /Users/dev/work/queue.jsonl からクライアントタスクを 1 件ずつ読み込み、 各タスクをドラフト→ローカル評価→ /Users/dev/work/done/ に出力してください。 12 タスクごとにコンテキストチェックポイントを保存し、電源交換後に復元できるようにすること。 キューが空になるか、バッテリーが 5% を切ったら停止。 制約を正直に宣言したシステムプロンプトが、エージェントに「自分の家の事情」を完全に理解させた。インターネットなし・メモリ有限・電源も有限、そして操作者は空の上にいる——何か起きても誰も介入できない状況だ。 ...

2026年5月、SNSで注目を集めた一本のポストがある。会社員として働きながらAI×SNS副業で月30万円を達成したエンジニア・おさぼり（@1osabori）氏が「英語圏のClaude Codeガチ勢がクライアントから月50万〜200万取ってる手法、Anthropic公式が30分でほぼ全部喋っちゃう」と発信した。そのポストは83万インプレッションを超えた。 この記事では、Anthropicが公式に公開しているドキュメントとガイドをもとに、英語圏のフリーランサーたちが実践している具体的なテクニックを解説する。 なぜ日本人が知らないのか 英語圏では Claude Code を活用した高単価フリーランスという働き方が急速に広まっている。Anthropicは「How Anthropic teams use Claude Code」という公式ドキュメントや「Best practices for Claude Code」で、社内エンジニアが実際に使っているワークフローを詳細に公開している。 しかしこれらのコンテンツはすべて英語で書かれており、日本語圏には届いていない。おさぼり氏が「日本人で知ってる人1%もおらん」と指摘するとおり、この情報格差が収益格差に直結している。 テクニック1: 計画先行ワークフロー（Plan-First Approach） Anthropicエンジニアが最も強調するのが「実装より前に計画を立てる」という原則だ。 Claude Code には plan モード（Shift+Tab を2回押して切り替え）があり、このモードでClaudeはコードを書かずに計画だけを提案する。 # プロンプト例 「まずコードには触れずに、このAPIの認証機能をどう実装するか 設計案を提示してください」 実装と探索を分離することで「間違った問題を解決する」リスクを排除できる。一度のプロンプトで複雑なタスクを丸ごと投げるのではなく、ステップバイステップで進めることが品質の鍵だと公式ドキュメントは述べている。 テクニック2: 並列エージェントパターン 英語圏の高単価エンジニアが特に活用しているのが「複数のClaude Codeセッションを同時に立ち上げて並列で動かす」手法だ。 Anthropicの社内実践として紹介されているのは以下のようなパターンだ。 エージェント1: スタイルガイドの確認 エージェント2: プロジェクト履歴のレビュー エージェント3: バグのフラグ立て エージェント4〜8: 元の発見の検証 一人のエンジニアが複数のClaudeインスタンスを「チーム」として運用することで、従来は複数人が必要だったコードレビューや品質保証を一人でこなせるようになる。これがクライアントから高い報酬を得られる直接の理由だ。 テクニック3: ストップフックによる自動化 Stop Hooksは、Claudeがタスクを完了したときに自動でアクションを実行する仕組みだ。 settings.json の設定例: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 { "hooks": { "Stop": [ { "matcher": "", "hooks": [ { "type": "command", "command": "npm test && npm run lint" } ] } ] } } Claudeがコードを書き終わると自動でテストが実行され、失敗があればClaudeが修正する。このサイクルを人間が介在せずに回すことで、Anthropicエンジニアは「2〜3倍の品質向上」を報告している（プロジェクトによって異なる）。なお npm test の部分は実際のプロジェクト構成に合わせて変更すること。 ...

元 Vercel エンジニアで TypeScript 専門家の Matt Pocock 氏が、AI エージェントを複数並列実行するためのオーケストレーションライブラリ Sandcastle を OSS として公開した。このツールは「夜間に 5 タスクを並列で走らせて、朝にマージレビューだけする」という AFK（Away From Keyboard）開発 を現実のワークフローとして成立させる。 Sandcastle とは Sandcastle は TypeScript ライブラリで、AI コーディングエージェントを隔離されたサンドボックスの中で動かすためのオーケストレーション基盤を提供する。 主な機能は 3 ステップ： sandcastle.run() の一行でエージェントを起動する Sandcastle がサンドボックス化とブランチ戦略を管理する エージェントが作ったコミットを自動的にマージ対象のブランチに集約する サンドボックスプロバイダー Sandcastle はプロバイダーに依存しない設計で、以下をビルトインサポートする： プロバイダー インポートパス 種別 Docker @ai-hero/sandcastle/sandboxes/docker バインドマウント Podman @ai-hero/sandcastle/sandboxes/podman バインドマウント（rootless） Vercel @ai-hero/sandcastle/sandboxes/vercel 隔離（Firecracker microVM） No-sandbox @ai-hero/sandcastle/sandboxes/no-sandbox なし（インタラクティブ専用） ローカル開発では Docker Desktop が最も一般的だ。クラウド実行には Vercel の Firecracker microVM が選択肢になる。独自のコンテナ環境に接続する場合は createBindMountSandboxProvider や createIsolatedSandboxProvider でカスタムプロバイダーを作ることもできる。 クイックスタート パッケージ名は @ai-hero/sandcastle、npm で配布されている。 ...

AWS が 2026 年 4 月 28 日に開催したイベント「What’s Next with AWS 2026」で、Amazon Quick のデスクトップアプリ（Preview）が発表・リリースされた。エンタープライズ向けのセキュアな AI アシスタントとして、Claude Code を含む開発者ツールとの MCP 連携も備えている。 Amazon Quick とは Amazon Quick は AWS が提供するデスクトップ AI アシスタントで、ユーザーの日常業務を横断的に支援することを目的に設計されている。今回のデスクトップアプリリリース以前から Web・モバイル版が存在していたが、OS レベルの統合が加わったことで機能が大幅に拡張された。 対応 OS は macOS と Windows の両方。AWS アカウントは不要で、個人メール・Google・Apple・GitHub・Amazon 認証のいずれかでサインアップできる。 主な機能 パーソナル知識グラフによるコンテキスト学習 Amazon Quick はバックグラウンドで動作するデスクトップ常駐アプリで、ユーザーが明示的に接続した SaaS 統合（Slack・メール等）と、許可したローカルフォルダからエンティティ（人物・組織・プロジェクト・イベント・ドキュメント等）を抽出して「パーソナル知識グラフ」を構築する。会話のたびにゼロから始めるのではなく、蓄積したグラフを参照して返答するのが特徴だ。 データ取得経路は次の 3 つに限定されており、画面録画・キー入力フック・アクセシビリティ API といった OS レベルの「横取り」は行わない: Auto-ingest from integrations — 接続済み SaaS の正規 API 経由でメッセージ・送受信者などを取り込む。Slack / Email / その他のソースタイプごとに個別トグルで ON/OFF ローカルフォルダ（オプトイン） — Settings > My computer でフォルダ単位に「Knowledge graph extraction」を明示的に有効化したフォルダだけをローカルでインデックス化（クラウドにアップロードはしない） チャット内での手動追加 — 会話中にユーザーが指示してエンティティを追加 抽出した知識グラフは ~/.quickwork/ にローカル保存され、クロスデバイス継続のため AWS アカウントへバックアップされる。AI モデルの学習には一切使用されない。 ...