ベンダーのブログと公式ドキュメントで推奨が違う
設計根拠にするのはドキュメントの側です

発表記事を根拠に設計を始めようとしている方へ

新しい技術の発表ブログを読んで「この構成でいこう」と決めかけている方、あるいは開発会社の提案の根拠がベンダーのブログ記事になっている方に向けて書いています。

主張は1つです。ブログとドキュメントが食い違ったら、設計根拠はドキュメントに置く。当たり前に聞こえますが、食い違いは実際に起きます。しかも発表直後の、いちばん判断を急ぐ時期に起きます。2026年8月に私たちが確認した実例から始めます。

実例: 同じベンダーの中で推奨が割れていました

OpenAIは2026年8月19日のブログで、エージェントの実行基盤を業務アプリへ組み込む構成を打ち出しました。目玉はapp-serverという接続方式です。出荷管理ダッシュボードに組み込んだサンプルまで公開し、エンジニアリング以外の業務にも広げられるとしています。

ところが同じOpenAIのSDK公式ドキュメントを読むと、案内が違います。このSDKの用途はコーディング中心のタスクだと明記され、より広い業務ワークフローの一部としてエージェントを使うなら、CLIをMCPサーバーとして立て、別のオーケストレーション用SDKから呼ぶ構成を推奨しています。

ブログが押す「直接組み込み」と、ドキュメントが案内する「MCP経由」。業務システムへの適用という、まさにブログが打ち出した用途で、経路の推奨が割れているわけです。

食い違いは悪意ではなく役割差です

これはOpenAIが不誠実だという話ではありません。文書の役割が違うのです。

ブログはマーケティングの文書です。新しい構成の最も見栄えのする形を示すのが仕事で、サポート体制や推奨範囲の宣言ではありません。一方リファレンスは、ベンダーが「この使い方は面倒を見る」と宣言する文書です。将来のバージョンアップで守られるのも、不具合時にサポートが受けられるのも、この宣言の範囲です。

だから順番はこうなります。リファレンス、ガイド、ブログ、登壇資料、SNS解説。下に行くほど鮮度は高く、信頼度は下がります。判断を急ぐ時期ほど下の情報しかないので、この順番を意識していないと、いちばん柔らかい根拠で設計を固めることになります。

SNS解説は2件とも間違っていました

最下層のSNS解説について、実測を1つ共有します。今回のOpenAIの発表を巡って広く読まれていた技術解説のうち2件を、一次情報と突き合わせて検証しました。結果は2件とも誤りを含んでいました。

1件は、発表ブログの要約に、元記事に存在しない他社事例の数字が混ざっていました。別のソースの数字が「この記事の内容」として流通していたのです。もう1件は、開発元がリポジトリで「実験的であり本番では頼るな」と明記している通信方式を、標準の接続方式として紹介していました。

どちらも悪意のある捏造ではなく、急いで書かれた要約の混線に見えます。しかし設計根拠には使えません。新しい言葉ほど、二次情報は汚れます。発表直後の技術については、解説の質を疑う前提で一次情報に当たるのが安全です。

採用判断の前に確認する4点

発注側にとっての意味

発表直後の技術は、情報の鮮度と信頼度が逆立ちしています。鮮度の高い情報ほど検証されていない。だからこそ、情報源の優先順位を先に決めておくことが、そのまま設計品質になります。

今回の実例に出てきた二大基盤の比較はCodexとClaude Codeの組み込み方式に、実行基盤という層の基礎はエージェントの本体はハーネスですに書きました。新技術の採用判断を一次情報ベースで整理したい場合は、お問い合わせからご相談ください。ドキュメントとブログの差分表を作るところからお手伝いします。