# Happy Birthday to Us: Honeycomb 10 Year Manifesto, Part 1 [[Honeycomb.io]] 創業 10 周年(2016 年創業)に合わせて、共同創業者 [[Charity Majors]] が書いたブログ記事(2026 年 2 月 11 日)。10 年前に掲げた原則を振り返り、AI 生成コードが大半を占める時代にもそれが通用するどころか、より切実になったと主張する。製品ベンダーによる立場表明(マニフェスト)であり、実証データは含まない。記事自体も末尾で「未来を解くのは我々だ」と自社の宣伝で締めくくっている。 ## 背景:Facebook での体験 Majors(運用エンジニア出身)と [[Christine Yen]](開発者出身)は、Facebook で使っていたツールがシグナルを分断された柱に撒き散らさず、文脈を 1 か所に集約していたことに衝撃を受けた。数日かかっていた複雑系の問題が自明になり、深い勘が要ったパターンをインターンでも見つけられるようになった。BI やプロダクト分析ツールの発想を借り、第一原理から本番のコード理解に必要なものを考え直すことが創業の動機だった。 ## 世界は変わったが原則は変わらない 10 年前の最難問はクラウド・マイクロサービス・コンテナ・多言語永続化による複雑性だった。いまの最難問も複雑性と変化の加速である。AI がコード生成のコストをほぼゼロに下げたため、ボトルネックは「作ること」から「学ぶことと検証すること」へ移った。 チームが苦戦しているのは、幻覚や非決定性といった AI 固有の部分よりも、本来退屈であるべき「ただのソフトウェア」の部分だという。量が 100 倍、速度が 100 倍になっただけである。既存の本番システムは、勘・手作業のパッチ・10 年在籍して文脈を頭に抱えた数人といった「ダクトテープ」で一定の変更速度に耐えてきた。変更速度が上がるとこのテープは剥がれる。知識がシステムに符号化されていなければスケールしない。 ## 10 年前に述べたこと - 複雑系は予測できない形で壊れる。道具はまだ思いついていない問いに答えられなければならない。 - 構造化ログイベントからメトリクス・ログ・トレースを導出できるが、逆はできない。イベントが真実の源泉(source of truth)である([[構造化イベント]])。 - 任意の次元で切れなければ推測しているにすぎない([[カーディナリティ]])。 当時は論争的だったこれらが今は自明になった、と著者は述べる。高カーディナリティ・高次元・柔軟性・速度・セマンティック規約・豊富な文脈という、人間が第一原理でソフトウェアを理解するのに必要な性質は、そのまま AI が良い仕事をするのに必要な性質でもある。浅いデータセットからは価値がほとんど出ない。これが [[AIOps]] の欠陥だったと著者は断じる。 ## 現在の 9 つの命題 1. **未知の未知(unknown-unknowns)が例外ではなく設計になった**。従来のコードはミクロには既定で決定的で、予測不能な挙動はバグだった。AI システムは設計上予測不能である。同じ入力が異なる出力を生み、エージェントは別の経路を取る。何を探すべきか分かっている前提の道具はすでに失敗している。 2. **文脈は事後に組み立て直せない**。AI システムの障害では、プロンプト・モデルのバージョン・検索(retrieval)段階・ユーザー入力・インフラ、あるいはその相互作用のどれが原因かを問う必要がある。三本柱に分断した道具は関係を破壊し、3 つのツールを事後に相関させても復元できない([[オブザーバビリティの三本柱]])。 3. **大半の人はどの問いを立てるべきか知らない**。ダッシュボード・クエリ・アラートは既知の指標とパターンを前提にしており、オブザーバビリティは常に専門性を前提としてきた。専門性を要するオブザーバビリティは上位 1% のためのものにすぎない。 4. **学習には速度が要る**。呼び出し(ページ)の閾値は高く、性能変化・コストの漸増・エッジケース・前日のデプロイの副作用は検知されないまま通り過ぎる。気づいた時には原因と結果の距離が開き、コードを書いた人も文脈も消えている。速く精密で具体的な道具と、開発時間を増やすのではなく減らす計装が要る。100 倍速で生成するなら、ボトルネックは書くことから意図の検証へ移る。 5. **仕事の単位が変わった**。20 年間、ソフトウェアの原子単位はリクエストだった。いまの仕事は数分から数時間続く会話、分岐・再試行・人間の介入を含むエージェントワークフロー、12 のサービスに触れ数日完了しないバックグラウンドパイプラインである。トレースモデルは仕事に明確な境界があると仮定していたが、それが崩れつつある。オブザーバビリティはサービス間だけでなく時間をまたいで働く必要がある([[分散トレーシング]])。 6. **トークンは新しい計算資源である**。性能は CPU・メモリ・レイテンシ・スループットといった償却される資源だったが、推論は要求ごとに直接かつ変動的に課金される。効率はサーバー稼働率からトークン利用率へ移り、コストは容量計画ではなく設計の問題になる。トークンを一級の次元にしなければ見えない。 7. **インターフェースは利用者の居場所に合わせる**。Cursor が示したように、チャットはインターフェースの 10% で、残り 90% は差分やファイルなど仕事そのもののドメイン固有表現である。多くの観測ツールはダッシュボードにチャットボットを足したが、それは逆向きだという。インターフェースは自律度のダイヤルであり、オートパイロット(気づく前に処理)・コパイロット(運転中に助言)・アナリスト(人が調査を指揮し証拠を集める)を課題ごとに切り替える。 8. **人間はループから去らない**。AI はシステムをより複雑にする。変わるのは仕事の性質で、問い合わせより判断、問題探しより対処の理解、トイルより判断に時間を使う。人間はループの中(in the loop)で決定し、ループの上(on the loop)で意図の宣言・試験・検証を通じてシステムの振る舞いを長期に舵取りする。 9. **開発ループと運用ループには別の道具が要る**。運用ループは alert → debug → fix でサービス全体の健全性を守り、三本柱はこの用途のために作られた。開発ループ build → test → merge は、従来の道具では計装が難しく分析もほぼ役立たなかったため本番を含まなかった。しかし価値も学習も本番でしか生まれない。運用には木槌が、開発にはメスが要る。AI により、開発者が意図を宣言し、コードを生成し、意図を試験し、デプロイし、開発環境を離れずに本番で意図を精密に検証できるようになった。ただし関係を保持したテレメトリの上に精密な道具があることが前提である([[オブザーバビリティ駆動開発]])。 ## 未来像と結論 著者は Cory Ondrejka の「o16g Manifesto」(Outcome Engineering)を引き、エンジニアリングは昔からコードではなく技術で事業の問題を解くことであり、チームにエージェントが加わっても団体競技であり続けると述べる。少人数で広い範囲を担えるようになり、エンジニアと管理職・プロダクト・事業・デザインの境界が曖昧になる。運用出身者にとっては、運用の卓越性がそれ自体で競争上の差別化要因になり、同時に AI ネイティブな社会技術システムが依存するガードレールになる時代だという。 結論は「文脈がすべて」である。シグナル間の関係はシグナル自体より重要かもしれない。複数の柱に撒いたシグナル、浅いデータ、存在論的な混乱は AI では直せず、AI はむしろ機能不全を増幅する。高カーディナリティ・高次元、1 秒未満のクエリ、変更ごとに学ぶ速いフィードバックループ、変更を数日から数週間追跡してバグを顧客より先に見つけるエージェントが要る。人間にとって Honeycomb 流オブザーバビリティを強力にした性質が、100 倍速でシステムを理解・運用しようとする AI エージェントにとっても強力である、とまとめる。 ## 既存 wiki との接続 - 命題 2・9 の主張は、[[Observability Engineering 2nd Edition]] の構造化イベント論(第 5 章)と、本番で開発者の意図を検証する議論(第 2 章)をマニフェスト形式に圧縮したものにあたる。 - 命題 6 のトークンコストを一級の次元にする主張は、[[GenAI オブザーバビリティ]] で未解決の問いとして残っている「コスト属性の標準化」と直接つながる。 - AIOps の失敗を「浅いデータ」に帰する診断は、[[AIOps]] 側の文献(モデルや手法の改良に焦点)とは原因の置き方が異なる。データの深さと関係の保持が律速だという仮説は、検証可能な問いとして残る。 - 冒頭の「10 年前は論争的、今は自明」という自己評価は、同じ著者が書籍第 3 章でオブザーバビリティの定義を守る戦いには「地滑り的に敗北した」と認めていることと温度差がある。原則の受容と用語の受容を分けて読む必要がある。 ## 関連 - エンティティ: [[Charity Majors]] / [[Christine Yen]] / [[Honeycomb.io]] / [[Cory Ondrejka]] / [[Cursor]] / [[Facebook]] - 概念: [[オブザーバビリティ]] / [[構造化イベント]] / [[オブザーバビリティの三本柱]] / [[カーディナリティ]] / [[GenAI オブザーバビリティ]] / [[AIOps]] / [[分散トレーシング]] / [[オブザーバビリティ駆動開発]] - ソース: [[@2026__OReilly__Observability Engineering 2E - Chapter 3 The Origins of Observability in Software]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 2 How Code Crosses Over - Validating Developer Intent in Production]] ## 出典 - 原文: https://www.honeycomb.io/blog/honeycomb-10-year-manifesto-part-1 - raw: [[.raw/articles/honeycomb-10-year-manifesto-part-1-2026-09-23.md]]