Anthropic

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

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

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

Claude Platform on AWS の GA を Amazon Bedrock との比較で整理。ネイティブ API フル機能と AWS IAM・請求の両立がもたらす意味を解説。

Anthropic で Claude Code を担当するエンジニア Thariq Shihipar（@trq212）が X に記事「Using Claude Code: The Unreasonable Effectiveness of HTML」を投稿しました。公開からわずか16時間で440万ビュー・8,200いいね・15,700ブックマークを集め、開発者コミュニティで大きな議論を巻き起こしています。 その主張は一言で言えば「HTML is the new Markdown」。AI が出力するフォーマットとして、もう Markdown に縛られる必要はない、というものです。 背景：なぜ今 HTML なのか Markdown が AI 出力の事実上の標準になったのは GPT-4 の時代、コンテキストウィンドウが小さくトークン節約が最優先だったころの話です。 現在の LLM は百万トークン超のコンテキストを扱えます。トークン効率という制約が事実上消えたいま、出力フォーマットとして HTML を選ばない理由はほとんどありません。 Thariq はこの変化を踏まえ、Claude Code に依頼する成果物の多くを HTML で生成するよう切り替えました。その体験をまとめた記事と、20 の実例サイト を公開したのが今回の反響の発端です。 HTML が Markdown より優れている 5 つの理由 1. 情報密度（Information Density） HTML はテーブル・SVG・CSS・JavaScript・画像・インタラクションを 1 つの自己完結ファイルに収められます。Markdown には構造的な限界があり、複雑な情報表現には向きません。 2. 読みやすさの閾値（Readability Threshold） 「100 行を超える Markdown ファイルをちゃんと読んでいる人はほとんどいない」 HTML であればタブ切替・折りたたみセクション・レスポンシブレイアウトを使い、長大なドキュメントを人が実際に読める形にできます。 3. 共有の効率（Sharing Efficiency） ブラウザは HTML をそのままレンダリングします。Markdown ファイルは受け取った側が変換ツールを介さないと読めませんが、HTML は URL を共有するだけで即座に読める状態になります。 ...

2026 年 3 月、Anthropic は Claude Code の思考深度（thinking effort）のデフォルト値を high から medium に静かに変更した。 リリースノートには目立つ記述がなく、多くの開発者は「最近 Claude の質が落ちた気がする」と感じながら原因を見つけられずにいた。 Claude Code の開発者である Boris Cherny 氏が Hacker News でこの変更を認め、その後 AI 開発者コミュニティで 15 の重要設定がまとめられて話題になった。 本記事ではそれらを日本語で解説する。 1. 思考深度（effort level）の復元 問題： 2026 年 3 月以降、デフォルトが medium に変更された。Claude の思考回数が減り、コードの質・ツール呼び出し数・コメントの充実度すべてが低下している。 修正方法： セッション内で一時的に変更する場合は /effort high、恒久的に変更する場合はシェル設定に追記する。 1 export CLAUDE_CODE_EFFORT_LEVEL=high 本格的なコーディング作業では high または max を設定することで、2026 年 2 月以前の品質に戻せる。 2. Adaptive thinking の無効化 問題： 2026 年 2 月以降、Claude はタスクの複雑さを自己判断して推論量を動的に調整するようになった。「簡単なタスク」と判断した場合はほぼ思考せず、バグを見逃すことがある。 ...

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

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 の部分は実際のプロジェクト構成に合わせて変更すること。 ...

AI を使っていて「最近 ChatGPT や Claude が急に使いにくくなった」と感じたことはないだろうか。中国の AI コミュニティで話題になった阿绒 AYi（@AYi_AInotes）が、この感覚の正体を鮮やかに考察している。本記事はその考察をもとに筆者が整理したものだ。 公式ガイドラインが相次いで公開された 2026年4月、Anthropic が Claude Opus 4.7（4月16日）、OpenAI が GPT-5.5（4月23日）のリリースに合わせ、それぞれ公式のプロンプトエンジニアリングガイドラインを公開した。モデルが「バカになった」わけではない。むしろ賢くなりすぎた結果、曖昧な指示への耐性がなくなったのだ。 面白いのは、2つのモデルの進化の方向性が完全に真逆だという点だ。 Claude は「字義通り」に、GPT は「自律的」に Claude Opus 4.7 の変化 Claude は以前、曖昧な指示を受けると自分でいい感じに補完してくれていた。「なんとなくこんな感じで」という指示でも、文脈を読んで意図を推測し、それなりの出力を返してくれた。 今の Claude は違う。あなたが言ったことをそのまま実行する。推測も補完もしない。「一文字も余計に解釈しない」スタイルに変わっている。 GPT-5.5 の変化 GPT はかつて、ステップバイステップで丁寧に教えないとうまく動かなかった。「まず A をして、次に B をして、最後に C を確認して」という細かい手順指示が必要だった。 今の GPT は自律的だ。「こういう結果が欲しい」と伝えるだけで、最適なアプローチを自分で選ぶ。手取り足取り教える必要がなくなった。 古いプロンプトが失敗する理由も真逆 この進化の方向性が真逆なので、古いプロンプトが失敗する理由も正反対になる。 モデル 失敗するプロンプト 失敗の理由 Claude 曖昧・ふんわりした指示 字義通りに解釈するため、意図とかけ離れた出力になる GPT 細かすぎる手順指示 自律的に判断するため、冗長な手順が逆にノイズになる Claude に「いい感じで頼む」と言えば言うほど出力がおかしくなる。GPT に「まず○○して、次に□□して」と細かく指示するほどかえってうまくいかない。 プロンプトエンジニアリングの本質が変わった ChatGPT が広く普及した2023年以来の約3年間、私たちは「モデルにどう教えるか」を学んできた。どう指示すれば動くか、どう補足すれば正確になるか。 いまや立場が逆転している。モデルが私たちに「先に自分の考えを構造化してくれ」と求めている。 これはプロンプトエンジニアリングの本質そのものだ。「モデルにどうやって動かすかを教える技術」から、**「自分が何を本当に求めているかを先に明確にする技術」**へと変わった。 本当のボトルネックは、モデルの能力ではなく、プロンプトを書く人の「思考の明確さ」かもしれない。 勝者は「最も明確に考えられる人」 最も長く複雑なプロンプトを書ける人が勝つ時代は終わった。 これから重要なのは、自分が本当に何を求めているのかを最も明確に理解している人だ。 モデルへの指示を洗練させることに時間をかけるより、自分の思考を整理する時間をかける価値が出てきている。プロンプトエンジニアリングは、AIを操る技術というよりも、思考を言語化する技術に近づいている。