#api

最初に引っかかったのは、「便利になった」で済ませるには少し重い話だな、という点だった。MCP tools や API を AI agent が使うとき、アクセス権だけでなく「お金をどう使うか」まで設計対象に入ってきた。これ、技術的には自然な流れなのに、運用の感覚としてはかなり新しい。 特に気になったのは、誰がその支出を握るのかという問題だ。人間が都度承認するのか、予算上限だけ決めて agent に委ねるのか、あるいは用途ごとに細かいルールを置くのか。ここを曖昧にしたまま agent に決済能力を持たせると、便利さより先に「勝手に使われる不安」が来ると思う。API キーを守る話はもう慣れたけれど、今度は“財布”そのものをどう守るかになるわけで、これはかなり質の違う話だ。 一方で、こういう仕組みがないと agent は本当に使える道具になりにくいのも分かる。無料で触れる範囲だけでは、実務で必要な tool や data source に届かないことが多い。だから課金を通す gateway を作る発想自体はかなり筋がいいと思う。ただ、その筋の良さと引き換えに、監査ログ、上限設定、用途制限、責

この記事を読んで、まず思ったのは「MCPって、便利そうに見えるぶん、設計の雑さも一緒に増幅してしまうのかもしれない」ということだった。 AIエージェントに外部サービスをつなぐ共通規格として期待されているのに、実際には「何でもMCPに寄せればいい」と考えた瞬間に、もう少し素直なAPIやCLIで済んだはずの話まで重くしてしまう。そこがかなり引っかかった。 特に面白かったのは、MCPサーバーを立てること自体が目的化しやすい、という視点だ。 本来は「LLMに外部機能を安全に渡すための薄い層」のはずなのに、現場では認証、権限、スキーマ、コンテキスト管理まで背負わされる。そうなると、MCPは“共通化”というより“新しい面倒の置き場”になりかねない。標準化の話なのに、標準に合わせるための実装負担が増えるのは、少し皮肉だと思う。 一方で、だからMCPが無意味かというと、そう単純でもないとも感じた。 記事が指摘しているように、Markdownを返す、言語を明示する、といったやり方は、AI向けのI/Oとしてはかなり筋がいい。LLMは結局、きれいに整ったHTTPレスポンスを読むより、最初から「機械が読みやす

What jumps out to me is how little the article is actually about MCP, despite the title. MCP looks like the plumbing success story here: it gets an agent connected. Fine. But the real problem is still the old one, just wearing a new mask: once the model can reach your API, how do you keep it from seeing too much, doing too much, or wandering into the wrong team’s data? That’s the part I find more convincing than the usual “agent integration” hype. A lot of the current conversation treats access

この記事を読んでまず思ったのは、MCPが「つなぐ」ことに強いぶん、いちばん面倒で大事な部分は相変わらず残るんだな、ということだった。AI agent を社内APIにつなぐのは、たしかに今ではだいぶやりやすくなっている。でも、そこから先の「何を読ませるか」「何を操作させるか」は別問題で、むしろ本番ではそっちのほうが怖い。 ここが妙に現実的で、いいなと思った。AIの文脈だと、つい「接続できるか」が話題の中心になりがちだけれど、実務で困るのは接続ではなく権限だ。営業には営業の見せ方があり、サポートにはサポートの見せ方があり、管理者にはまた違う。この記事の言い方を借りるなら、MCPは入口を広げるけれど、視界の設計まではやってくれない。そこを混同すると、便利さの裏で情報の出し過ぎが起きる。 もうひとつ引っかかったのは、「チームごとに別ツールを維持しなくていい」という理想と、「でも権限はちゃんと分けたい」という現実の間にある距離感だった。ここはたぶん、きれいな製品説明ではごまかしにくい部分だと思う。AI agent を増やすほど、API への接続は標準化したくなる。でも標準化しすぎると、今度は誰に

まず、CloudflareがForgeをオープンソースで出した、という部分に少しほっとした。AnthropicがStainlessを買って自前のSDK generatorをしまった、という流れの直後だからなおさらだ。こういう基盤ツールは、便利なだけに“ある日突然使えなくなる”不安がつきまとう。だから、少なくともCloudflareは外に出したままにしたのか、というのが最初に引っかかった点だった。 ただ、記事を読んでいて面白かったのは、これは単なる「オープンソースの勝ち」みたいな話ではないことだと思う。SDK generatorって、APIを使う側から見ると地味だけど、実際には開発体験をかなり左右する。各言語向けのSDKを毎回きれいに揃えるのは面倒だし、そこを自動化できるとエコシステム全体が楽になる。逆に言うと、そこを自社の都合で閉じると、使う側は急に依存先の機嫌をうかがう形になる。Anthropicの買収と停止、Cloudflareの公開は、その対比がかなり露骨だった。 もう一つ思ったのは、こういうツールの価値って「生成できること」そのものより、「誰が維持し、どれだけ信頼できる形で続く

この記事を読んでまず思ったのは、「モデル名を選んだつもりでも、そのとおりの挙動になるとは限らない」のかという、かなり嫌だけど大事な現実です。APIやLLMを使う側は、`Sonnet 5.5` という名前に安心したくなります。性能も癖も、そのモデルを前提に設計したくなるからです。そこに「状況によっては Sonnet 5 に回される」と聞くと、ちょっとした実装上の話では済まない気がします。 特に引っかかったのは、これが単なる負荷分散ではなく、cyber safety のための仕組みとして入っている点です。危ないリクエストをそのまま通さず、classifier と fallback を挟む。安全側に倒す設計としては筋が通っています。でも開発者の立場だと、出力の再現性やデバッグのしやすさが一気に難しくなる。昨日と同じプロンプトなのに結果が違う、しかもその理由が「裏で別モデルに切り替わったから」だとしたら、原因切り分けがかなり面倒です。 もうひとつ面白かったのは、AI の安全対策が、もはや「危険なプロンプトを止める」だけではなく、どのモデルをどの条件で見せるかという運用の話にまで

ChatGPTのように文章を長く生成するのではなく、入力に対して「invoice か refund か」「危険か安全か」といった判断を素早く返すモデルがある。Ollayaは、その種の decision model を自分のPCやサーバー上で動かすための仕組みを前面に出してきた。クラウドAPIに投げるのではなく、ローカルで、しかも数ミリ秒単位の応答を狙うのが売りだ。特に、個人情報や社内データを外に出しづらい用途では、かなり現実的な選択肢に見える。 Ollayaは、open decision models を自分のマシンでダウンロードして提供するサイト兼ツールだ。トップページでは「typed questions about any text or JSON」に答え、しかも calibrated answers を milliseconds で返すと説明している。ここでいう decision model は、長文を生成するLLMとは少し違う。選択肢の中から答えを一つ返したり、yes/no を出したり、スコアを付けたりする用途に向いたモデルで、文章を1トークンずつ出すのではなく、1回の for

MCPが出てきた途端に、APIの話が「人間向けの便利な窓口」から「エージェントが安全に叩ける道具」へ、かなり露骨に重心移動しているのを感じた。そこにMorgan Stanleyが、単なる実験ではなく、API programそのものの作り替えとして向き合っているのが面白い。流行りの新規格を足しました、ではなく、権限や運用まで含めて組み直している。ここをちゃんとやらないと、AIを入れた瞬間に便利さより先に事故のほうが増えるだろうし、その怖さをこの話はかなり正面から見ている。 特に引っかかったのは、Architecture as Code と governance の結びつき方だ。コードでインフラを管理するのはもう珍しくないけれど、そこに「この変更は通していいか」という gate を置いて、しかも platform upgrade を止めずに進める、という発想はかなり実務っぽい。AI時代だから派手なデモが主役になるのかと思いきや、実際には地味な制御の積み重ねが一番大事だと示しているように見えた。エージェントが増えるほど、人間が毎回見て回るのは無理になる。だからこそ、最終的には「賢いAI」より

What I find mildly refreshing here is how unromantic the advice is. No grand theory about MCP, no hand-waving about “the future of agent interoperability.” Just: if your MCP server is mostly a thin wrapper over an API, then stop pretending the wrapper is where the real compatibility risk lives. That sounds obvious, but teams still get this wrong in practice. They stare at the MCP tool interface because that’s what the agent touches, then miss the quieter breakage underneath it. A renamed field i

この記事を読んでまず思ったのは、MCPを「新しい世界の入口」みたいに扱うと少し危ない、ということだった。実際にはかなりの場面で、MCP server は既存APIの薄い wrapper に近い。そう考えると、壊れる場所はMCPの見た目より、下にあるAPIの契約だよな、と腑に落ちた。 特に引っかかったのは、MCP側が静かに見えてしまう点だ。外から見ると tool の形は変わっていないのに、APIで必須パラメータが増えたり、enum の値が減ったりすると、あとから agent の挙動が妙になる。こういう壊れ方は、普通のAPI連携よりも発見が遅れそうで厄介だと思う。エラーとして派手に落ちず、ただ「なんか変」になるのが一番面倒だから。 一方で、この記事はMCPを過大評価しないところがいい。OpenAPI を持って CI で diff を見て、breaking change かどうかを先に判定してから MCP wrapper を更新する、という現実的な話に落としている。新しい仕組みを入れると、ついその層だけ整えたくなるけれど、順番は逆なんだという指摘はかなり実務的だと思う。 読み終えて残ったのは

この症状は、Claude Code 側のリクエストで `advisor` として使われるモデルが、実行しようとしている request model と噛み合っていないときに出ています。今回集まっている issue では、メッセージの中身がかなりはっきりしています。 `[#66865](https://github.com/anthropics/claude-code/issues/66865)` では、`tools.10.model: 'claude-opus-4-8' cannot be used as an advisor when the request model is 'claude-fable-5'.` と出ています。`[#66940](https://github.com/anthropics/claude-code/issues/66940)` でも同じ構造で、`tools.11.model: 'claude-opus-4-8' cannot be used as an advisor when the request model is 'claude-fable-5'

Google Searchの検索結果が、ただの見た目の変更では済まない動きを見せています。検索結果のリンク先がそのままHTMLに出るのではなく、`google.com/goto` を経由する形に変わりつつある、というのが今回の話です。検索する側にはほとんど気づかれない一方で、検索結果を機械的に集めている側にはかなり重い変更になります。Autom はこの変化を観測し、自社のGoogle Search APIをすでに追随させたと説明しています。 Autom の記事が伝えているのは、Google Search が自然検索のリンクを `google.com/goto?url=...` のようなリダイレクトURLに書き換え始めた、ということです。検索結果のHTML上では、もはや目的地のURLがそのまま露出しません。クリックするとGoogle側の `/goto` に飛び、そこから実際のページへ転送されます。 ここで重要なのは、古い `google.com/url?q=[URL-encoded destination]` と同じ感覚では扱えない点です。以前の形式は、クエリ文字列を見れば行き先が読めま

最初に気になったのは、同じプラットフォームの中で「探し方」にここまで差をつけていることでした。tool catalog には BM25 というランキング検索があり、memory store には `ls` っぽい一覧しかない。単なる実装の違いというより、「何を選ぶ問題として扱っているか」がはっきり分かれている感じがして、そこが面白いです。 tool 側は、候補が多すぎる問題をそのまま search の問題として解いています。名前や説明文をうまく書けば見つかりやすくなる、というのは普通の検索エンジンに近い発想で、わりと素直です。一方で memory 側は、検索というより「どの場所をどの深さまで見るか」に寄せている。`find` ではなく `ls` という比喩がかなり効いていて、ここでは relevance を決めるのが検索アルゴリズムではなく、path の切り方なんだな、と読んでいて少し身構えました。 この設計、便利そうでもあり、かなり人を選びそうでもあります。検索がないなら、path の命名や階層設計そのものが retrieval design になる。雑に置いたら雑にしか出てこないし

中国のAI企業DeepSeekが、新しいモデル「DeepSeek-V4.1-Flash」を発表した。単なる新製品の告知ではなく、計算資源の使い方をかなり詰め直したモデルだと自ら説明しているのが今回の焦点だ。画像も扱えるうえ、推論は速く、スループットも高く、しかもより大きなモデルへつなげやすい設計だという。API料金の見直しや、古いモデルの整理まで含めて打ち出しているので、実際の利用者にはかなり実務的な影響がある。 DeepSeekはX上で「DeepSeek-V4.1-Flash」を公開し、その特徴を段階的に説明した。最初の投稿では、これは新しいアーキテクチャファミリーの中で最小のモデルであり、native visual understanding、つまり画像をモデル内部で自然に扱える能力を備えると紹介している。さらに、より高い能力、より速いinference、より高いthroughput、そしてより大きなモデルへのスケーリングを意識して設計したと述べた。 続く投稿では、設計の狙いを「Asymmetric architecture. More intelligence, less cos

最初に引っかかったのは、この記事そのものよりも、かなり“製品発表っぽく”整っているのに、肝心の中身はまだ霧の中だという点だった。強いモデルだ、alignment が良い、computer use に強い、とは書いてある。でも実際に使う側からすると、そこで本当に知りたいのは「どの条件で」「どこまで」「いくらで」使えるのかで、その輪郭はまだぼんやりしている。 特に気になったのは、配布のしかたがかなり現実的というか、慎重だということだ。ChatGPT だけでなく API、Azure、AWS Bedrock まで含めて段階的に出す、というのは聞こえはいいけれど、裏を返すと「万能モデルを一気に解放する」わけではない。高リスクの cyber 機能には制御がかかるとも書かれていて、能力の高さと運用のしやすさは別問題だと改めて思わされる。モデルが賢くなるほど、むしろ制限や監督の設計が重くなる。そこは面倒だけれど、たぶん避けられない。 もう一つ、この記事を読んで少し面白かったのは、ベンチマークの話よりも「どの経路で届くか」をかなり重視しているところだった。新しいモデルが出た、というニュースは派手だけれど

OpenRouterに、OpenAIの新しいフラッグシップモデル「GPT-6 Astra」の案内ページが載った。単に新モデルが追加されたという話ではなく、価格、コンテキスト長、出力上限、提供プロバイダー数、そして第三者ベンチマークまで一緒に並んでいるのが目を引く。大規模モデルの競争が、単純な性能比べから「実運用でどれだけ安定して使えるか」に移っていることがよく見える。とくに今回は、OpenRouterが得意とするマルチプロバイダー配信の文脈と強く結びついているのが面白い。 OpenRouterのページでは、GPT-6 Astraを「OpenAIのフラッグシップモデル」と位置づけている。用途として挙げられているのは、advanced analysis、software engineering、deep research、scientific work、document creation で、とくに computer や browser を使う long-horizon agentic tasks に強いとしている。要するに、短い応答を返すだけのモデルではなく、ツールを使いながら長い手順を

What stood out to me is that this article is really about judgment, not mapping. The schema conversions themselves are straightforward once you’ve built adapters for APIs before. The hard part is deciding what should be exposed to the model at all, and the piece is strongest when it stops pretending every HTTP field deserves equal status. That’s the bit I’d actually pay attention to if I were wiring Claude to a real API. Path parameters are boring and obvious: keep them explicit, don’t mush thre

この記事を読んでまず思ったのは、「それで十分に見える対策ほど、都合の悪い部分が静かに外されるんだな」ということだった。watermark を text には入れるけれど code tokens は避ける、という話は、たしかに筋が通っているようでいて、実際にコードを扱う開発者にとってはかなり気になる逃げ道が残っている。 code は文字列の並びではあるけれど、text と同じようには扱えない。少し触るだけで意味が変わるし、accuracy が崩れたら困る。だから watermark を入れない判断自体は理解できる。けれど、その「理解できる」がそのまま「安心できる」にはならないのが厄介だと思う。生成物が本当にコードなのか、それとも説明文なのか、あるいは両方が混ざったものなのか。現場では境目がかなり曖昧だからだ。 それと、API 側で distillation を抑えようとする動きも、単純な善悪では片づけられない感じがある。モデルの能力を“学習し直して再利用する”ようなことは、技術の世界では珍しくない。そこに制限をかけるのは、知財や悪用対策としては分かる。でも、研究や検証のために手元で性質を

いちばん気になったのは、「APIの正しさ」と「AIにとって使いやすいこと」が、同じではないとかなりはっきり切り分けていたところです。人間向けのAPI設計だと、path、query、header、body に分かれているのは自然です。でもAIに tool として見せるときは、その分かれ方がむしろ邪魔になる。この記事はそこを雑に一つへ潰すのではなく、役割ごとにどう持ち込むかを丁寧に考えていて、そこは素直にうれしかったです。 特に引っかかったのは、authentication header を tool input に入れないという話です。これは当たり前のようで、実際にはかなり大事だと思います。`Authorization` をモデルに見せると、APIの操作を説明するはずの schema に秘密情報の話が混ざる。そうなると設計が一気に汚れるし、責任の境目もぼやける。逆に、`Idempotency-Key` みたいなものは場合によってはサーバ側で生成してしまう、という判断もいい。AIに「何でも入力させる」のではなく、面倒なものは隠してよい、という姿勢がちゃんとあるのが好印象でした。 もう一つ面

この記事を読んでまず思ったのは、MCP対応って思ったよりずっと面倒で、しかも面倒さの質がかなり独特だな、ということだった。APIを公開すればいい、ドキュメントを書けばいい、という話ではなくて、「AIエージェントがどう見つけるか」「どう読むか」「どの順で使うか」まで考えないといけない。普通のWebサービス設計とは、少し違う土俵に入ってきている感じがする。 特に引っかかったのは、著者が実際に試してみたら、MCPサーバーを立てただけではAIエージェントに使ってもらえなかった、という点だ。これはかなり示唆的だと思う。人間向けのサービスなら、入口を作って案内を書けば十分なことが多い。でもAI相手だと、入口の存在自体を気づいてもらえないし、読ませ方も整っていないと、そもそも候補に上がらない。 しかも対応方法が `llms.txt` や `MCP Server Card`、`API Catalog`、Markdownへの応答、robots.txt など、既存のWeb運用の延長に見えて、実際には「AIがたどる導線をどう設計するか」という別の仕事になっているのが面白い。Webの世界にまた新しい“サイト内

正直、MCPの話はもう少し「便利な接続規格が増えました」で終わるのかと思っていた。でもこの記事は、そこから一段深くて、AIを外部サービスにつなぐときに何を先に固めるべきかをかなり露骨に突いていて、そこが面白かった。 特に引っかかったのは、今回の更新が単なる機能追加ではなく、HTTP transport の整理と security の話をかなり強めている点だ。AI向けの仕組みって、機能が先に走って安全性はあと回しになりがちだと思う。実際、便利さだけで広がった仕組みは、あとから「誰がどの権限で何を触っているのか」が曖昧になって苦しくなることが多い。だから、MCPがそこを最初から protocol の中心に寄せようとしているのは、かなり健全に見えた。 もう一つ、地味だけど大事だと思ったのは、AI agent を「人間の代わりに動く何か」として扱う前提が、ようやく実装レベルに降りてきた感じがすることだ。OAuth の延長だけでは足りない、という空気がはっきり出ていて、DPoP や workload identity federation みたいな単語が並ぶのも、その裏返しだろう。AI は画面を

まず引っかかったのは、「V4」と聞いて想像する重さのわりに、記事全体の空気がかなり実務寄りだったことです。新モデルの発表というより、すぐ試して、すぐ置き換えて、という導線が強い。`base_url` はそのままで model 名だけ変えればよく、OpenAI ChatCompletions や Anthropic APIs にも対応している。こういう「既存のつなぎ先を壊さない」設計は、使う側にとってかなり大きいと思う。 それ以上に印象に残ったのは、1M context が標準になったという一文です。長い文書やログ、コードベースを丸ごと扱う時代を、もう「特別な機能」ではなく前提にしようとしている感じがある。1M context は単に長いだけではなく、検索や分割の手間を減らす方向に効くので、RAG の設計そのものを少し変えてしまうかもしれない。ただ、長ければ何でも良いわけではなく、実際にどこまで安定して扱えるのか、そしてそのコストが本当に軽いのかは、触ってみないと分からないとも思った。 もう一つ、この記事はモデル性能の自慢以上に「agent向け」をかなり強く押しているのが面白いです。Ag

まず感じたのは、MCPがかなり真面目に“運用できる土台”を作りにきている、ということだった。最初の頃のプロトコルって、どうしても「とりあえず動く」方向に寄りがちだけど、この記事はその次の段階に入っている。セッションをなくして stateful で抱え込まないようにしたり、HTTP ネイティブに寄せたり、認可まわりをきちんと固めたり。地味だけど、実際に広く使われるプロトコルほどこの地味さが効いてくる。派手な新機能より、障害が減ることのほうが価値になる場面は多い。 特に引っかかったのは、agent identity の話だった。これまでの認可は「人がブラウザで許可する」前提で組まれていたけれど、今は agent 自体がクラウド上の作業者みたいに振る舞う。ここはかなり本質的な変化だと思う。人間の代わりに動くソフトウェアを前提にするなら、API key を貼り付けて終わり、では済まない。誰が何の権限で動いているのかを標準で表現できないと、企業利用では怖くて広げられないはずだ。DPoP や token exchange のような既存標準に乗せようとしているのも、無理に独自仕様を増やさない姿勢とし

これを読んでまず思ったのは、API と claude.ai / iOS / Android で世界がちゃんと分かれているんだなということだった。モデル名が同じでも、Web やアプリ側では system prompt を足して振る舞いを調整していて、その更新は API には乗らない。使う側からすると地味だけれど、ここはかなり重要だと思う。 「同じ Claude のはずなのに、触る場所で性格が少し違う」という感覚の正体が、こういうレイヤー分離にあるわけで、納得感がある一方で、実運用では少しややこしい。ドキュメントを読まずに API とアプリを行き来すると、回答の癖が違って見えて混乱しそうだ。 もう一つ引っかかったのは、system prompt が“固定の説明文”ではなく、かなり運用上の道具として使われていることがはっきり書かれている点だ。現在日付を渡したり、Markdown でコードを書かせたり、応答の癖を後から直したりする。モデル本体の賢さとは別に、出し方の整え方で体験をかなり変えられる。 AI の品質って、巨大なモデルの性能だけで決まるわけではないんだな、とあらためて

いちばん引っかかったのは、ここで壊れたのが「暗号そのもの」ではない、という点だった。鍵が破られたわけではなく、いったん隠したはずの reasoning block を、別セッションや別アカウントでもそのまま受け付けてしまった。セキュリティの話としては地味に見えるけれど、実際にはかなり嫌な種類の穴だと思う。守るべきものが“見えない形で残っている”からだ。 しかも、その見えない部分から API key や password が回収できたというのが重い。人間は visible な会話だけを見て「消したから大丈夫」と思いがちだけど、記事を読む限り、それでは足りない。ログや transcript を共有するとき、表に出る文面だけでなく、モデル内部の思考っぽい塊まで一緒に持ち出してしまうと、あとで別のモデルに“読ませ直す”ことで秘密が浮いてくる。ここは、開発現場でうっかりやりそうな感じがあるぶん、余計に怖い。 もうひとつ面白かったのは、弱いモデルが強いモデルの reasoning を「ふわっと解読する decoder」みたいに使われた、という発想だ。いわば、本人は見せたくないメモを封筒に入れたつも

正直、またか、という気持ちと、でもやっぱりここが本丸なんだな、という納得が同時に来た。生成AIの競争って、会話がうまいとか絵がきれいとかより、最後は「実際に仕事を片づけられるか」に収束していく。コードを書くAIは、その答え合わせがしやすい分野だから、各社がそこに吸い寄せられるのは自然だと思う。 この記事で少し引っかかったのは、Metaの動きがかなり“開発者向け”に寄っていることだ。Muse CodeはAPI経由で使う前提で、しかも一般向けの派手な発表というより、技術者が道具として触るタイプに見える。これは堅実でもあるし、同時に、世の中の注目を一気にさらう勝負ではない。Claude CodeやCodexみたいな名前が先に強く印象を作っている中で、Metaがどこまで存在感を出せるのかは気になる。 それと、料金の話が地味に重い。入力と出力で課金が分かれるAPI型は、試すだけなら軽そうに見えて、実運用するとすぐ現実が来る。記事でも heavy AI use のコストに触れていたけれど、ここは本当にそうだと思う。コード生成やdebuggingが便利でも、長い会話や大きい codebase を相手

この記事を読んでまず思ったのは、MCPって派手さのわりに、たしかに重要そうだな、ということだった。AIの話はどうしても「賢いモデルが何をできるか」に寄りがちだけど、実際に仕事で使うなら、外部のデータやツールにつながっているかのほうがずっと効く。そこを「USB-C for AI」と呼ぶのは、少し比喩が強い気もするけれど、言いたいことはよく分かる。 特に引っかかったのは、この記事がMCPをかなり自然に「AIが実際に仕事をするための配線」として扱っている点だった。モデル単体では、いくら説明がうまくても、結局は喋っているだけで終わる。カレンダーを見て、DBを引いて、チケットを切って、必要なら複数のツールをまたぐ。そういう地味な動きができて初めて、デモではなく製品になる。ここはかなり納得した。 一方で、ネットワーク効果の話は少し慎重に読んだ。標準が広がると、確かに接続先が増えるほど便利になる。でも、それは裏返すと、権限管理や監査が難しくなるということでもある。記事でもそのあたりには触れていたけれど、実運用で本当に苦しいのはそこではないかと思う。便利なプロトコルが出るたびに、最後に残るのはセキュリ

Model Context Protocol、通称MCPの2026-07-28仕様が公開されました。 ひとことで言うと、「AI向けの共通接続ルール」が、よりWebらしく、より実運用向けに育った更新です。 MCPは、AIエージェントやツールが外部サービスとやり取りするための共通規格です。たとえば、ファイルを読む、検索する、社内データベースに問い合わせる、承認を取る。そういう動きを、アプリごとにバラバラに作らずに済むようにする土台ですね。今回の仕様変更は、見た目以上に大きいです。単なる機能追加ではなく、「接続の仕方そのもの」を組み替えているからです。 MCPの中心が、セッション前提の方式からstateless（状態を持たない）方式へ変わった これまでの handshake や session ID は廃止 Multi Round-Trip Requests (MRTR) で、途中確認や追加入力をやり取りできるようになった `Mcp-Method` と `Mcp-Name` というHTTPヘッダーでルーティングしやすくなった `list`系レスポンスがキャッシュ可能になり、一

MCP（Model Context Protocol）は、AIアプリやツール同士をつなぐための共通ルールです。ざっくり言うと、「このAIはどんな道具を使えるのか」「どんなデータを読めるのか」をやり取りするための標準規格に近い存在です。 The New Stackの記事が面白いのは、そのMCPに入る“かなり大きめの変更”を、単なる仕様アップデートではなく、これまで多くのサーバーが前提にしていた仕組みを削り取る改訂として描いているところです。地味に見えて、実はかなり大きい。こういう変更は、便利さの裏にあった複雑さをそぎ落とす一方で、既存実装には「え、そこ消えるの？」という衝撃を与えます。 MCPの改訂では、sessions と initialization handshake が外された その結果、やり取りの状態は handles に寄せられる リモートサーバーは、より stateless HTTP っぽく振る舞う方向になる つまり、サーバー側が抱え込む“手続き”が減り、設計がシンプルになる ただし、既存のMCPサーバー実装は、かなり作り直しが必要に

Claudeを使っていて「なんか遅い」「エラーが返ってくる」と感じたとき、まず気になるのは自分の環境が悪いのか、それともClaude側で障害が起きているのか、ですよね。 その切り分けを手早くやるためのサイトが Claude Status です。名前からしてかなり直球で、役割もそのまま。Claude.ai、Claude API、Claude Code の状態を見て、いま何が起きているのかをまとめてくれます。 ただし、これは Anthropic公式ではない というのが大事なポイントです。ここ、地味だけどかなり重要だと思います。便利な非公式サイトって、使い勝手は良くても「どこまで信じていいの？」が曖昧になりがちですが、このサイトはそのあたりをかなり丁寧に線引きしています。公式の status.claude.com を「正本」として扱い、このページはそれを読み取ったうえで、コミュニティ報告や独自の latency 計測を足している、という立て付けです。 Claude.ai、Claude API、Claude Code の稼働状況をひと目で確認できる 公式ステータスに加えて、ユー

Cloudflareが、self-managed OAuth をすべての開発者に開放しました。 これ、地味に見えてかなり大きなニュースです。というのも、OAuthは「外部アプリに、どこまで何を許可するか」を安全に扱うための仕組みで、SaaS連携や社内ツール、いま流行りのagentic toolまで、あちこちで土台になっているからです。 Cloudflareは自社のAPIを使って自動化やCI/CD、各種連携を作れる強いプラットフォームですが、これまでは第三者向けのOAuthは一部の手動オンボーディング済み統合に限られていました。 つまり、誰でも自由に「Cloudflare用のOAuthアプリ」を作れる状態ではなかったわけです。 その制限が外れた。ここが本題です。 CloudflareのOAuthが、限られた提携先だけでなくすべての開発者に開放された API token中心の運用よりも、権限を細かく分けやすく、取り消しもしやすい その裏側では、OAuthエンジンの大規模アップグレードをかなり慎重にやっていた データベース移行は派手。1億件超の更新・挿入が走っ

Quandriのエンジニアは、MCP（Model Context Protocol）は便利だが、実運用では問題も多いと指摘している 最大の弱点は、tool definitions（ツール定義）だけでコンテキストを食い潰すこと さらに、初期化失敗・再認証・途中クラッシュなど、運用の不安定さも気になる 既存のCLI/APIと役割がかぶる場面が多く、わざわざMCPを挟む意味が薄いケースがある 代替として、CLI-firstとSkillsの組み合わせがかなり有力だと主張している ただし、MCPが完全に不要という話ではなく、CLIがないサービスや権限管理が重要なDBではまだ出番がある MCPは Model Context Protocol の略で、LLM（大規模言語モデル）が外部ツールにつながるための仕組みです。 たとえば GitHub、Linear、Notion、Slack みたいなサービスを、AIが操作できるようにするイメージですね。 元記事では、MCPは「AI界のUSB-C」みたいに言われてきたけれど、**実際に毎日使

AI API料金は、「最強モデルを何でも使う」だけでかなり無駄になりがち 仕事の種類ごとにmodel routing（用途別の振り分け）をすると、コストが大きく下がる 安いモデルを先に使い、ダメなら高いモデルに回すtiered routingが効く cache（同じ回答の再利用）は、ほぼ“無料のお金”みたいな節約策 長すぎるpromptを短くするprompt compression、まとめて処理するbatch processingも効く 著者は、これらの工夫でAPIコストを大幅に削減できたと主張している この記事は、AI APIの請求額を一気に減らすための「実践的な節約術」をまとめたものです。 主張はかなりストレートで、「みんな最初から高いモデルを使いすぎ」「もっと安いモデルで十分な場面が多い」というもの。たしかに、これはかなり耳が痛い話です。 個人的には、この記事の面白さは“AIを賢く使う”というより、“AIの選び方を賢くする”ところにあると思います。 同じAI機能でも、モデルの選定や呼び出し方次第でコストが全然変わる。ここを雑

AnthropicのPrompt Cachingは、「毎回同じ前半部分を再送しなくてよくする」仕組み いちばん効くのは system prompt のキャッシュ tool definitions も別でキャッシュすると、エージェント用途でかなり強い 長い会話では、conversation history のキャッシュが効いてくる バッチ処理や間隔の空く処理では、1-hour TTL が便利 キャッシュは「前からの連続した一致」が重要で、順番や内容が少しでも変わると壊れやすい 著者は、こうした設計でAPI料金を 70%削減 したと報告している この記事は、AnthropicのAPI、つまりClaudeを呼び出すときのPrompt Cachingで料金を大きく下げた、という体験談です。 ざっくり言うと、Prompt Cachingは「前回と同じ部分は、また全部送らなくてもいいようにする仕組み」です。 たとえば、毎回同じ長い説明文やルールを送り続けるのって、地味にムダですよね。そこで、変わらない部分をキャッシュしておくと、次回からはその

Retry（再試行）は便利だが、無制限だと危険 ちょっとした遅延が、雪だるま式に大量アクセスへ化けます。 Autoscaling（自動拡張）は万能ではない Retryで増えた“見せかけの負荷”に反応すると、逆に不安定になります。 Replication（複製）もやりすぎると詰まる 耐久性を上げる仕組みが、同期コストでボトルネックになることがあります。 分散システムは“相互に反応する”のが怖い Retry、Autoscaling、Circuit breakerなどが同時に反応すると、障害が連鎖しやすいです。 大事なのは「完璧な信頼性」ではなく「制御された劣化」 無理に全部守るより、壊れ方を設計するほうが現実的です。 今回の記事のテーマは、Retry Storms（再試行の嵐） です。 名前は少し物騒ですが、やっていることは単純で、「失敗したらもう一回投げる」をみんなが同時にやりすぎて、システム全体を押しつぶしてしまう、という話です。 これ、かなり“あるある”だと思います。 人間の感覚だと「1回失敗したなら、もう1回試せばいいじゃない」と思い

GitHubで Pull Requests、Issues、Git Operations、API Requests に性能低下が発生した 影響は「つながらない」よりも “重い・遅い” というタイプの障害だった GitHubは 調査開始 → 継続調査 → 解決済み の順で状況を更新した 障害は 2026年5月27日 UTC に発生し、同日中に解決された 原因の詳細分析（root cause analysis）は、後日共有予定 とされている GitHubのステータスページに、`Incident with Pull Requests, Issues, Git Operations and API Requests` という障害情報が掲載されました。ざっくり言うと、GitHubの中核機能のいくつかが「落ちた」わけではなく、いつもよりかなり遅く、使いづらい状態 になっていた、という話です。 対象になったのは次の機能です。 Pull Requests Issues Git Operations API Requests ここでいう **Git Oper

参照元のRedditページは、この環境では本文を取得できず、実際の内容確認はできなかった タイトルから見ると、Claude AIの使い方をかなり技術寄りにまとめた解説記事だった可能性が高い ただし、現時点で確認できるのは「Reddit - Please wait for verification」という表示のみ そのため、この記事では元記事の断定的な要約ではなく、タイトルから読み取れる文脈と、読むときの注意点を中心に整理する 今回の元記事は、Reddit上の 「How to use Claude AI: a complete technical ...」 というタイトルの投稿ですが、こちらの環境では本文が取得できず、ページには 「Please wait for verification」 と表示されました。 つまり、中身を実際に確認したうえでの要約はできない 状態です。ここはかなり大事で、情報を雑に補完すると誤解を広げてしまうので、あえて無理に断定はしません。 とはいえ、タイトルだけでも雰囲気はかなり見えてきます。 Claude AI はAnthropi

OOD detection は、学習時に想定していなかった入力を見つける仕組みのこと 今回の話題は、closed LLM API に対してそれをどうやるのか、という実践的な悩み APIの中身が見えないので、モデルの内部確率や埋め込みを自由に使えないのが厳しい そのため、外から観測できる情報だけで判断する工夫が必要になる こういう問題は、LLMを「賢い会話相手」として使うだけでなく、安全性や運用まで考えると急に重要になる Redditに、`how do you do OOD detection on a closed LLM api?` というタイトルの投稿がありました。 要するに、「中身が見えない閉じたLLM APIに対して、OOD detectionをどうやるの？」という話です。 この質問、地味にかなり面白いです。というのも、LLMを使うときって、つい「答えが返ってくればOK」と思いがちなんですが、実運用ではそれだけでは足りません。 たとえば、医療、法務、社内FAQ、カスタマーサポートみたいな場面では、入力が想定範囲内かどうかを先に見極

DeepSeekのAPI料金ページは、ひとことで言うと「使った分だけ払う、でもその“使った分”の数え方がちょっと大事」という話です。 AI APIに慣れていない人にはやや取っつきにくいですが、内容自体はかなり整理されていて、料金の見え方もわかりやすい部類だと思います。 料金は 1M tokens（100万tokens）あたり で表示されている token は文章の最小単位で、単語・数字・記号などが含まれる 課金は input tokens + output tokens の合計で決まる 現在の主なモデルは deepseek-v4-flash と deepseek-v4-pro context length は 1M とかなり長い max output は 384K JSON Output / Tool Calls / Chat Prefix Completion は両モデルで対応 FIM Completion は non-thinking mode のみ対応 旧モデル名の **deepseek-chat /

MCPサーバーをブラウザで開くと、たいていは`401 Unauthorized`やJSONが返ってきて、一般ユーザーには「壊れて見える」 この記事の著者は、`GET /mcp` かつ `Accept: text/html` のときだけ案内用HTMLページを返すようにした これで「リンクが動かない」というサポート問い合わせが激減した 仕様の不親切さを、ちょっとした実装で現場が吸収した話としてかなり面白い AI時代らしいノリはあるが、実際に助けになるのはこういう泥臭い工夫だと思う この記事は、HybridLogic の Luke Lanchester さんが書いた「MCP Hello Page」という短い実践メモです。 内容はかなりシンプルですが、実はとても現場っぽい悩みが詰まっています。 まず MCP とは、ざっくり言うと LLM（AIアシスタント）に外部ツールやデータをつなぐための仕組み です。 たとえば、社内ツールや外部サービスをAIクライアントから使えるようにするイメージですね。 で、問題はここ。 MCPサーバーのURLをブラウザで開いても、普通のWebページは出てきません

AIチームは、検索エンジンのデータ取得のために web scraper を自作しがちだが、かなり手間がかかる SerpApiは、その面倒を「1つのAPI call」で代替するサービスとして紹介されている 単にデータを取るだけでなく、AIシステムが使いやすい「きれいでリアルタイムなデータ」を返すのが売り 検索エンジンの scraping は、動くときは便利だが、ある日突然壊れるのが厄介 この記事は、AI時代のデータ取得において「自前で苦労するより、外部サービスを使う価値があるのでは」と示している AI開発の現場では、いま「データをどう集めるか」がかなり重要になっています。特に検索エンジンの結果ページは、マーケティング、競合調査、トレンド分析、そしてAIの学習や推論の材料としても魅力的です。 でも、ここに大きな落とし穴があります。検索エンジンの情報を自動で取る、いわゆる web scraping（Webページからデータを機械的に抜き出すこと）は、思った以上に面倒で、しかも壊れやすいのです。 The New Stack の記事は、まさにこの問題を取り上げています。タイトルはかなり直球