こんにちは、LIFULL HOME'Sのネイティブアプリ開発チームでエンジニアリングマネージャーをしている佐々木です。 「この画面、何が表示されてるか教えてもらえますか？」 目の前のタスクに集中しているときにSlackに飛んでくるこの一文で、エンジニアの手は止まります。悪気はない。でもチームのリードタイムは確実に伸びていく。 この問題を、AIに業務知識を構造化して渡すことで解消した話をします。 背景：人間が"コンテキストの運び屋"になっていた 試行錯誤：最初からこの形だったわけではない 何を作ったか：業務知識をパッケージ化する なぜ効いたか：3つの設計判断 ① 定義の集約：誰がいつ聞いても同じ答えが返る ② スキル化：「やりたいこと」を伝えるだけで手順が走る ③ ツール統合：分析もチケット起票も1箇所で完結 成果：「聞く側」も「聞かれる側」も変わった 余談：世界では「コンテキストレイヤー」と呼ばれているらしい まとめ 背景：人間が"コンテキストの運び屋"になっていた 私たちのチームでは、メイン施策を進めている最中に、次の施策のための質問・相談が頻繁に飛んできていました。 PdMから：「この画面の表示ロジックってどうなってる？」 デザイナーから：「この機能、実装上の制約ある？」「この表現はコード的に可能？」 マーケから：「この数値、どのイベントで計測されてる？」 エンジニアは手を止めてコードを読み、回答する。1往復30分〜数時間。これが毎日何回も発生していました。 問題はそれだけではありません。質問する側も「エンジニアの手を止めてしまう」という心理的ハードルを感じていて、遠慮して質問を溜め込む → まとめて聞く → 大量の回答待ちが発生する、という悪循環もありました。 本質は明確でした。 チームの業務知識が人の頭にしかなく、AIが参照できる形になっていなかった 。 試行錯誤：最初からこの形だったわけではない 前提として、利用者は非エンジニアです。GitHubアカウントを持っていない人がほとんどで、 git clone もターミナルも使えない。この制約の中で、どうやってコードベースの知識をAIに渡すか。 最初に試したのはGoogle GeminiのGem（カスタムAI）+ GitHub連携でした。でも連携した本人しか使えず、チームには共有できない。NotebookLMも同じ問題。 Repomix （コードを1ファイルに圧縮するツール）も試しましたが、ディレクトリ構造やファイル間の関係性が失われ、調査精度が出ませんでした。 結局たどり着いたのは「コードをそのまま同梱してzipで配る」という原始的な方法でした。全員が同じ環境を使えて、コードの構造もそのまま残る。「Googleドライブからダウンロード→解凍→フォルダを開く」だけで始められる。これが一番確実だった。 何を作ったか：業務知識をパッケージ化する 作ったのは、チームの業務知識を構造化してAIエージェントに渡す「パッケージ」です。zipを解凍して Kiro IDE （AIエージェント機能を内蔵したエディタ）で開き、日本語で質問するだけで使えます。 パッケージの中身は3層で構成されています。 steering（ルール・定義） : KPI定義、データソースの所在、業務上の制約 skills（手順・ナレッジ） : 分析の手順、レポート作成の方法、調査の進め方 agents（専門家） : コード調査担当、データ分析担当など、役割に特化したサブエージェント 3層構造の概念図 このしくみを、現在4チームに展開しています。 対象チーム 当初の課題 利用者 状態 ネイティブアプリ開発チーム 仕様調査でエンジニアの手が止まる PdM・企画・デザイナー ✅ 稼働中 デジタルマーケティングチーム 数値管理・レポートが手作業で属人的 マーケター ✅ 稼働中 アプリ広告運用（ASA/ASO）チーム 運用判断に専門知識が必要 企画・マーケター 🔶 一部利用 賃貸・流通領域チーム 仕様調査の横展開 PdM・企画・デザイナー 🔶 検証中 このほかにも試作段階のものがあり、少しずつ適用範囲を広げています。 このしくみの展開により、従来のコミュニケーションフローが大きく変わりました。 Before/Afterフロー比較 なぜ効いたか：3つの設計判断 ① 定義の集約：誰がいつ聞いても同じ答えが返る 「この指標の定義は？」「この計算式の出どころは？」。これまで人の頭にしかなかった情報を、Markdownファイルに一元管理しました。誰がいつ聞いても、AIが同じ定義に基づいて同じ答えを返します。属人化が構造的に解消されるしくみです。 ② スキル化：「やりたいこと」を伝えるだけで手順が走る 「着地見込を出して」と伝えるだけで、AIがデータ取得→計算→フォーマット整形まで実行します。利用者は「やりたいこと」を伝えるだけでよく、手順を知っている必要がありません。業務手順の暗黙知がスキルとして構造化されているからです。 ③ ツール統合：分析もチケット起票も1箇所で完結 BigQueryでの数値分析も、Jiraへのチケット起票も、Confluenceへの報告書投稿も、全部同じKiro IDEの中で完結します。「あの作業はスプレッドシート、この分析はGemini、あれはGoogle Apps Script」というツール跨ぎが消え、非エンジニアにとっての認知負荷が劇的に下がりました。 成果：「聞く側」も「聞かれる側」も変わった 利用者の一人である企画メンバーは、公式noteで以下のように書いてくれています。 以前は、「この仕様はどうなっていますか？」とエンジニアに確認を依頼し、その回答を待つまでに数時間〜1日ほどのリードタイムが発生していました。エンジニア側の作業を止めてしまうという心理的ハードルもありました。 しかし現在では、企画担当である私自らが調査パッケージを使い、5分〜10分程度でコードベースの一次調査を完結させています。コミュニケーションの往復が消えたことで、調査工数は約80〜90％削減され、施策検討のサイクルは圧倒的に加速しました。 — エンジニアから企画へ。LIFULL HOME'S アプリ部署で目撃した、AIシフトがもたらす「職種を越えた共創」 単に工数が減っただけではありません。「ここまで調べた結果、ここを変えれば実現できそうですが、どう思いますか？」という提案ベースの相談ができるようになったことで、意思決定の質も上がっています。 そしてエンジニア側は、調査依頼に中断されることなく、メイン施策の開発に集中できるようになりました。 余談：世界では「コンテキストレイヤー」と呼ばれているらしい ちなみに、2026年3月にa16z（米国の大手VC）が公開した記事「 Your Data Agents Need Context 」では、こう述べられています。 データ・分析エージェントは適切なコンテキストなしでは本質的に役に立たない。曖昧な質問を解きほぐすことも、ビジネス定義を解読することも、散在するデータを横断して推論することもできない。 同記事では、この問題の解決策として「企業のデータを束ね、ビジネスロジックを理解できる層をエージェントに供給する基盤」を「コンテキストレイヤー」と呼んでいます。振り返ると、私がやっていたことはまさにこれでした。 この記事を知ったのは後からです。現場の課題を解決していたら、同じ構造にたどり着いていました。 まとめ AIがどれだけ賢くなっても、チーム固有の業務知識を構造化して渡さなければ正しくは動きません。 大げさなプラットフォームがなくても、Markdownとスキル定義を整備してzipで配るだけで始められます。「人に聞く」を「AIに聞く」に変えるだけで、チームの循環は確実に変わります。 次回は、このしくみの技術的な設計と具体的なファイル構成について詳しく書く予定です。 最後に、LIFULLではともに挑戦し成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 https://hrmos.co/pages/LIFULL/jobs/010 https://hrmos.co/pages/LIFULL/jobs/010-9998

2026年5月21日に開催されたサポーターズ主催の「セキュリティLT会〜全エンジニアが知っておきたいセキュリティの話〜」で、株式会社ジーニー インフラ部 クラウドインフラチームの中島潤が、SBOMを活用したサプライチェーンリスク可視化に向けた取り組みを紹介しました。 本記事では、その内容をもとに、ジーニーでSBOMをどのように活用しているのか、導入によって何が変わったのかをご紹介します。 SBOMとは SBOMは Software Bill of Materials の略で、ソフトウェアを構成するコンポーネントやライブラリ、依存関係を一覧化したものです。 食品でいう「原材料表示」の

AI時代の検索サービス：生成AIがサイト内検索に与える影響 ※本記事は、2026年4月28日開催の「Product Management Summit 2026」におけるセッション「AI時代の検索サービス：生成AIがサイト内検索に与える影響」の内容をもとに作成したものです。 ※登壇者：セールス&マーケティングプラットフォーム事業部 MA/CDP/SEARCH開発部 SEARCH開発 レコメンド・AI SEARCHチーム PdM/EM 三浦 宏貴 生成AIの普及により、ユーザーの情報探索行動は大きく変わり始めています。これまで主流だった「キーワードで検索し、検索結果から複数の