みなさまこんにちは！エアークローゼットでCTOをしている辻です。 「AIで全部変わる」という風潮がありますが、私が社内でAI活用基盤(cortex)を組み立て、そして運用してきた実感はむしろ逆です。原理は何も変わらない。ただ仕組みだけが変わる。この記事では、私が何を原理ととらえ、何を壊すべきと考えてきたのか、その思想について紹介します。 これまでcode-graph、product-graph、db-graph、biz-graph、AI-Observability、auto-review harness、Self-Healingと、個別の実装について書いてきました。今回はそれらの話ではなく、全部の背後にある設計原理そのもの。個別実装から一段抽象度を上げた、思想寄りの話です。 その原理とは、一言で言えば「正確な情報に、適切にアクセスできるようにするには？」という設計問題です。これは実は人類が
みなさまこんにちは！エアークローゼットでCTOをしている辻です。 設計編では、アプリケーション / インフラ / CI / LLMの4軸を、それぞれの問いの性質に合わせて別々の形でObservableにする話を書きました。ここまでで観測スタックの書き込み側は一旦区切ったところです。 ただし、「Observableにしただけ」で話は終わりません。観測スタックには本番データが流れる以上、ここにPIIが混入する経路を断たないといけない ── これはAIとは無関係に、observability設計で手を抜くと漏洩事故に直結する古典的な問題です。 従来、ログを読める人の集合はDBを読める人の集合とほぼ重なっていました。DB権限を持つエンジニアにとって、ログは個人情報への「追加の」経路ではなかった ── つまりログ側の防御は、システム全体の防御線を実質的には動かしにくい位置にあった、というのが多くの現
「全部OTelに乗せて全部Lokiに流せばいいじゃん」という選択肢は確かにあります。でもそうすると、「リアルタイムの『今いくら』」と「『先月の累計をteam別に集計』」のような質的に違う問いを1つのbackendで答えようとして、どこかが苦しくなる。ここを目的別に分けたのがcortexの選択です。 以下、4つの軸を順に書きます。アプリケーションとインフラは「土台」として簡単に触れ、CIとLLMはAI時代特有の設計判断が出るので深掘りします。 アプリケーション ── OTel + Loki + Tempoの標準スタック 土台はシンプルです。cortexの各アプリケーションはOpenTelemetryで計装していて、traceはTempo、logはLoki、metricはMimirに流す ── というGrafana Cloudの標準形。 ここは特別な工夫はしておらず、重要なのは「全アプリが同じ
みなさまこんにちは！エアークローゼットでCTOをしている辻です。 前編で、46リポジトリに跨る本番システムのコードベースを静的解析で1つのナレッジグラフに統合した話を書きました。完成はしたものの、最後に4つの課題（セマンティック検索ができない / ノード爆発 / 関数の中身はファイルを見ないと分からない / 新parser追加の運用負荷）が残っている、という話で終わりました。 今回はこのうち、最初の「セマンティック検索ができない(入口問題)」をどう解いたかという話です。残り3つは前編の状態のまま残しています ── 後半の「まだ解けていない課題」のセクションで、入口問題を解いた結果あらためて見えてきた次の課題と一緒に整理します。 入口問題から始める理由は単純で、graphができても、そこに辿り着くための入口がgrepしかないなら、結局AIは推論せざるを得ない。「事実として渡す」という本来の目
みなさまこんにちは！エアークローゼットでCTOをしている辻です。 今回は、複数サービス合計46リポジトリに跨る本番システムのコードベースを、静的解析で1つのナレッジグラフに統合した話です。 社内ではcode-graphと呼んでいて、今年の1月から3月にかけて構築しました。 書き残しておきたい論点が3つあります。 なぜ「コードを読ませる」だけでは足りなくて、リポジトリを跨いだ繋がりまで取りに行く必要があったのか 46リポジトリに散らばる多種多様なフレームワーク（jQuery / AngularJS / Express / NestJS / TypeORM / Redux Axios ...）の境界をどう抽出していったか 3ヶ月の試行錯誤の結果、何が解けて何が解けなかったか 本記事は前編で、code-graph自体の構築と苦労、そして残った課題までを書きます。後編では、code-graphをb
起点 ── 2025年に考えていたこと cortexを作り始めた頃、自分が答えを出したかった問いは1つでした。 どうやってAIにシステムを正確に理解してもらうか AIがシステムを正確に理解できさえすれば、PRレビューもバグ調査も修正も任せられるし、エンジニアではないメンバーにも開発を開放できる、という直感がありました。逆に言うと、「正確に理解してもらう」ところで詰まっている限り、その先のすべては不安定に乗っている。だから機構ごとの工夫よりも前に、前提のところをどう実装するかを考える時間が長かった。 ただし、ここに対する素直なアプローチはいずれも壁にぶつかります。 壁1: コンテキストウィンドウの限界 最初に考えるのは「必要そうな情報を全部渡せばいいのでは」というアプローチです。コードベース全部 + ドキュメント + DBスキーマ + インフラ定義をプロンプトに乗せれば、AIは全体像を把握で
注記: 本記事で言及する「cortex」は、airCloset社内で独自開発したAIプラットフォームの内部コードネームです。Snowflake CortexやPalo Alto Networks Cortex等の既存商用サービスとは一切関係ありません。 Part 1（総論）で、cortexのハーネスが組み上がってきた結果、エンジニアではないメンバー（事業サイドのマネージャー、PMOなど）も本番リポジトリにPRを出せるようになってきた話を書きました。ここで言うハーネスはAIを本番で動かすための土台で、Part 1-4で順に解説してきたナレッジグラフ / Auto Review / Self-Healing / 再発防止の組み合わせのことです。 Part 5はその続きで、そのハーネスが「誰が書くか」のレイヤーまで波及している話です。 「いやでも、品質をAIレビューに任せきって本当に大丈夫なのか
注記: 本記事で言及する「cortex」は、airCloset社内で独自開発したAIプラットフォームの内部コードネームです。Snowflake CortexやPalo Alto Networks Cortex等の既存商用サービスとは一切関係ありません。 Part 3では「AIが書いたコードはAIが見る」── 自動レビューパイプラインで PR時点の品質を守る話を書きました。 今回は本番時点の品質を守る側、Self-Healing（自己修復）です。本番アラートをAIが調査して修正PRを起票、自動レビューに乗せて自動マージ、自動再デプロイまで完結させる仕組み。そしてその修正PRには再発防止のlint/型ゲートの追加が必須化されていて、結果としてガードレールが日々自動で増えていく。 「障害が自動で直る」だけだと派手で目を引きますが、たぶんそれだけでは中長期では負ける。直したついでに同じ罠の再発を構
これが今のcortexの「典型的な1ヶ月」。 世間でよく聞く「AIで開発スピードを上げても結局レビューが詰まる」「AIが書いたコードは品質が下がる」という声は、cortexの中では構造的に起こりにくいパイプラインで受け止めています。ここから順に分解します。 「AIが書くとレビューが詰まる」を構造で防ぐ 通説：レビューが新しいボトルネックになる AIで書く速度が上がるほど、書いたコードを見る側（レビュアー）の負荷が比例して増える。Anthropicの社内ブログ（How Anthropic teams use Claude Code）でも、書く側より見る側にボトルネックが移っていること、シニアエンジニアの仕事がコードを書くことよりAI出力を統合・レビューすることに寄ってきていること、が報告されています。 これはcortexでも実際に同じ現象が起きました。Claude Codeをフル稼働させた瞬
いきなり1つのシーンから 「KPIダッシュボードに出てる "バグ発生率" の計算ロジックを変えたい。どこにあって、何か壊れる？」── 実装に入る前に、こんな問いが立ったとします。 AIにこの問いをそのまま投げると、関数名もファイルパスも与えていないのに、AIはcpgをセマンティック検索で叩いて関連ノードを一気に拾います。返ってくるのは関数だけでなく、該当するBigQueryテーブルやAPIエンドポイントまで含めた候補リスト。レスポンス末尾の「次のアクション候補（Runbook）」を見て、AIは書き込み / 読み取りの両方が集まっているBQテーブルを起点にトレースを打ち直します。 最終的にAIが返してくる答えはこんな感じです: 計算箇所: calculateRatePer100pt / calculateBugCount ── どちらも純粋な計算関数で、外部I/Oは持たない（変更しても直接の
いきなり2つのシーンから シーン1: PRは無人でマージされる 月曜の朝、エンジニアがローカルで機能を実装し、ブランチをプッシュしてPRを出す。 数分後、AIレビュアーからREQUEST_CHANGESが付く。指摘は複数: 「同じデータ整形を共有パッケージのformatRow()がすでに実装しているので重複しています。共通化してください」 「APIのレスポンス型を変更していますが、関連するドキュメント（docs/api/...）の記述が古いままです」 AI対応エージェントがworktreeを切って、修正をコミット、プッシュ 再度のレビューでAPPROVE 自動でsquash merge 変更されたスタックだけがGitHub Actionsで検出され、Cloud Run / Cloudflare Pagesへデプロイ ここまで人間ノータッチで完了します。エンジニアはPRのタブを更新して、「あ
みなさまこんにちは！エアークローゼットでCTOをしている辻です。 これまでに DB Graph MCP、社内MCP群の全体像、Biz Graph、Sandbox MCP と、社内向けに作っているMCPサーバーを順に紹介してきました。 DB Graph は ORM 解析からのスキーマグラフ、Biz Graph は会議スライドからの施策抽出と Week ノード設計、Sandbox MCP はそもそもアプリ公開基盤 ── 目的も実装も全部違うのですが、自分でも書きながら気づいたのは、設計の根っこにある考え方は同じだということです。 今回はその根っこの話をします。Agentic Graph RAG ── 私たちが社内のいろんな領域でグラフを作るときに、繰り返し採用している設計フレームの話です。 「Graph RAG なら聞いたことある」「Microsoft の OSS でしょ？」と思った方、ちょっ
みなさまこんにちは！エアークローゼットでCTOをしている辻です。 これまで 社内MCP群の全体像、DB Graph MCP、Biz Graph、Sandbox MCP と、社内向けに作っているMCPサーバーを順に紹介してきました。 今回はその運用の中で見えてきた、自作MCPサーバーのトークン消費を減らすTips の話を書きます。 困りごと：MCPは意外とトークンを食う MCPでAIエージェントを拡張するとき、最初に遭遇するのが トークン消費が想定より多い という現実です。 MCPのツール呼び出しは、結局のところ JSON-RPC over HTTP です。AIが送る引数も、ツールが返す結果も、そのままAIの会話コンテキストに乗ります。素直に実装すると、 ファイル丸ごとを引数で送る → 数千行のソースコードがコンテキストに張り付く DBクエリ結果を全件返す → 数千行 × 数十カラムの表がコ
みなさまこんにちは！エアークローゼットでCTOをしている辻です。 これまでに DB Graph MCP、社内MCP群の全体像、Biz Graph MCP と、社内向けに作っている MCP サーバーを順に紹介してきました。 今回はその中でもちょっと毛色が違うものを取り上げます。Sandbox MCP ── 非エンジニアの社員が AI と一緒に作ったアプリを、ワンコマンドで社内に安全に公開できるプラットフォームです。 「Claude Code でアプリを作れるなら、それをそのまま社内に出せばいいじゃん」という話を、安全に実現する仕組みです。 背景：作るのは簡単になったが、公開は難しいまま Claude Code をはじめとする AI コーディングエージェントの普及で、いま社内の景色が大きく変わりつつあります。 これまで「アプリを作る」と言うと、エンジニアの仕事でした。要件定義してデザインを起こ
みなさまこんにちは！エアークローゼットでCTOをしている辻です。 前回の記事で全社DBを自然言語で横断検索できるMCPサーバーを紹介し、社内MCP群の全体像もお見せしました。今回はその中で「Biz Graph」と一言で紹介していたものを深掘りします。 施策と KPI の関係をグラフ構造で表現し、「あの施策、効果あったの？」に AI が答えられるようにした話です。 なぜ Graph RAG なのか AI をより活用するために重要なのは、データの羅列ではなくデータの関係性を伝えることです。 データ量がそこまで多くなければ NotebookLM のようなツールで十分に成果が出せます。しかし、ビジネスデータすべてをコンテキストに入れることは不可能です。施策の報告資料、KPI スプレッドシート、マーケの週報、物流の日次実績 — これらを全部まとめてプロンプトに突っ込むことはできない。 そのため、現状
みなさまこんにちは！エアークローゼットでCTOをしている辻です。 前回・前々回の記事では、社内の全DBを自然言語で検索できるDB Graph MCPと、17台のMCPサーバー群で社内業務をAIに開放したMCPサーバーを紹介しました。おかげさまでどちらも多くの反響をいただきました。 今回はMCPの話ではなく、もう少し手前の 「社内の情報基盤」 について、私がまず最初に情報化したいと思っていた"会議"の情報化を実現した話です。 Google Meet の 録画・文字起こし を、Slackチャンネルに 自動共有 し、さらに過去の会議内容を 自然言語で検索 できるようにした仕組みです。 課題：対面コミュニケーションの価値と、失われるコンテキスト 対面のコミュニケーションは、速いし密度が高い。テキストで30分かかる合意形成が、会議なら5分で済むことも珍しくありません。これが会議の最大のメリットです。
これらは全て TypeScript で実装され、Pulumi で GCP にデプロイされ、Google OAuth で認証されています。 設計思想 なぜこんなに分けたのか 1つの巨大な MCP サーバーに全機能を詰め込むこともできますが、あえてサーバーを分けています。理由は： 認証スコープの分離 — GWSサーバーにはWorkspace APIのスコープが必要だが、DBクエリサーバーには不要。スコープを最小限にすることで権限の暴発を防ぐ デプロイ独立性 — Grafanaサーバーの変更がDBクエリに影響しない。障害の爆発半径を小さくする ユーザーごとの選択 — エンジニアは全部入れるが、マーケチームはGWSだけ、のように必要なものだけ .mcp.json に追加すればいい 共通基盤 全サーバーに共通するパターンがあります。 認証: 共通パッケージで Google OAuth 2.0 + P
こんにちは id:masutaka26 です。夜の散歩（意味深）に勤しむ毎日です。 フィードフォースではドキュメント共有ツールには esa と Google ドキュメント1を、コミュニケーションツールには Slack を採用しています。 情報共有はかなり活発で、2021/2/1 現在の esa 記事数は 81,324 です2。 現在のカテゴリ構成と課題 チームのスピードを上げるための大原則 チームのスピードを上げるための情報整理 1. Flow 型と Stock 型の記事を理解する 2. 基本は Flow 型の記事にする 3. 議事録カテゴリは出来るだけ作らない 4. Slack に流れていく情報も Flow 型の記事にする 5. 使い続けられる情報を Stock 記事として引き上げる 6. 整理を頑張らないことで整理の難易度が低くなった 7. esa を全ての情報の起点にする それをチー
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog (2月5日 16:30追記) SNS等で多くのご指摘をいただき、再度掲載していたコードや表現について社内で議論いたしました。それを踏まえて以下の通り、補足および訂正させていただきます。 エラトステネスのふるいの実装方法については、高速化のための実装ではなく、アルゴリズムなどの勉強をしっかり行ってきたか、ということを示すための1例として紹介しましたが、あたかも高速化を目指したコードとしての例示となり、誤解を招く表現でした。上記の意図を明確にするために、本文中に高速化するための実装ではないことを明記しました。 また、"個性がない"という表現も、上記と同様に"アルゴリズムなどの勉強をしっかり行ってきたという実績や経験がコードから判断
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
