すべての業務活動のデジタル化したい、コーポレートエンジニアリング室の竹山 (@yuya-takeyama) です。
この記事は LayerX Tech Advent Calendar 2025 6 日目の記事です。
昨日は @civitaspo さんによるAWS→SnowflakeのWorkload Identity FederationをBashで実装して低レベルな処理を理解するの巻でした。
12 月になると讃美歌「荒野の果てに」を思い出します。「グロリア」をひたすら伸ばして歌うところのうねるメロディがとても印象的な曲です。
今日は年末ということで、2025 年のコーポレートエンジニアリング室の活動のうち、プラットフォーム的な側面に着目して振り返ってみたいと思います。
以前から私たちの活動を観察してくださっている方々には「オッ、やっとるな」と思っていただけると幸いです。また、それ以外でも私たちの活動に興味を持っていただいている方々には、最近の雰囲気をなんとなく感じていただけるのではと思っています。
「プラットフォーム」と言ったときに、私たちコーポレートエンジニアリング室の文脈としては大きく 2 つの意味があると考えています:
- 社内全体の活動を支える基盤 (Platform for Corporate)
- コーポレートエンジニアリング室の活動 (特にソフトウェアの開発・運用) を支える基盤 (Platform for Corporate Engineering)
今回は前者に焦点を当てて振り返ってみようと思います。
ABAC Generator によるグループ管理の自動化の拡大、AI エージェントによる設定変更の試み
ABAC Generator は平たくいうと「Entra 等のグループメンバーの更新を SmartHR の組織図に基づいていい感じに自動化」するためのツールです。
以前に以下の記事で詳しく解説しています:
- 生産性とガバナンスを両立したグループ管理のため、SmartHR 上の属性情報を元に擬似的な ABAC システムを構築した話
- claude-code-base-action で設定ファイル自動生成のための Agentic Workflow を作る
また、先日技術書展 19 において頒布した LayerX TechBook 1 においても「人と SaaS と AI エージェントが協業する権限管理」というタイトルで、ABAC Generator の設定ファイルを AI エージェントに書かせる試みについて解説しています。
2024 年末時点では、ABAC Generator によって管理されたグループは 88 個でしたが、2025 年末時点では 161 個にまで増加しました。この中には、部署の新設等によって新たに作られたグループもあれば、元々手動管理していたグループを ABAC Generator に移行したものもあります。これによって、毎月の入社・異動・退職に伴うグループメンバーの更新作業の大幅な削減を実現し続けています。
細かい改善としては、以下のようなものが挙げられます:
removedblock を用いた tfstate からのリソース削除に対応- 個別のメンバー除外に対応
- 追加のオーナー設定に対応
- 細かいメンバー条件を複数追加
これらはよりきめ細かい管理を可能にするための順当・連続的な改善といえます。
一方、ABAC Generator の利用の拡大や社員の増加に伴い、「従業員の問い合わせをもとに、設定ファイルに翻訳するのが煩雑である」という課題も顕在化してきました。去年時点ではほとんどの設定ファイルの記述を私が担当していましたが、今年は他のメンバーにもやってもらうことが増えてきました。私としてはとても助かっていますが、従業員からの要求を具体的な設定に落とし込むのは ABAC Generator の作者である私にとっても簡単ではないことが多く、それ以外のメンバーにとってはなおさらです。
面倒なことは AI にやらせよう、ということで、少しずつ AI エージェントに設定ファイルの生成を手伝ってもらう試みを進めてきました:
- 4 月ごろ: 既存のグループ設定の import を手助けする Import Agent を Mastra で開発
- 9 月ごろ: 新規グループの追加・既存グループの編集を実行するエージェントを claude-code-base-action で試作
- 10 月ごろ: claude-code-base-action で作ったエージェントを Claude Agent SDK を使った Group Config Agent として再実装
- LayerX TechBook 1 に詳細を記載
当初は単純なロジックでは生成が難しかった部分のコード生成のために LLM を使っているだけで、一番重要なメンバー条件の生成まではやっていませんでした。さらに、コードを文字列として生成するだけで、実際にファイルを変更するのは人間がコピペで行う、というところから始まりました。
そこから、SmartHR 上の部署をファジーに検索・取得するツールを組み込むことでメンバー条件の生成も少しずつできるようになったり、Claude Agent SDK を利用することで設定ファイルの変更・Pull Request の作成まで自動化できるようになっていきました。
すでにエージェントを利用して設定の追加・編集を行ったグループもいくつかありますが、実際の問い合わせに答えられるようにすることにはまだギャップがあることがわかってきました。実際の問い合わせは「この人たちが入ったグループを作って欲しい」と言った形で、メンバーの名前が挙げられるだけで、条件には落とし込まれていません。従業員は基本的に ABAC Generator をはじめとした一連のシステムについて知っているわけではないので、当然です。そもそも、自分や周囲の人々が所属する部署名を正確に把握していないことも多いです。思い返せば、前職でコーポレートエンジニアではなく SRE をやっていた頃の私も同様だったと思います。
問い合わせの担当者はメンバーの名前をもとに、所属部署や雇用形態などの情報を調べて、具体的な条件に落とし込んだり、それを問い合わせ者に確認したりする必要があります。これがなかなか手間です。従業員ごとの属性情報を取得したり、それらを整理して条件に落とし込む作業をツール・プロンプトに落とし込んでいくことで、より実用的なエージェントにしていきたいと考えています。
Dify/n8n の導入・活用の推進
2025 年の 4 月に、LayerX の行動指針の 1 つであった Bet Technology は Bet AI にアップデートされました。
これは、プロダクトへの AI を活用した機能の追加だけでなく、社内業務における AI の活用も強く推進していく、という意味合いを持っています。ChatGPT や Gemini などのチャットアシスタントはそれまでにもそれなりに使われていたり、エンジニアは Cursor のようなコーディングエージェントを使ったりしていましたが、より幅広い業務で、深く AI を活用していくことが求められるようになりました。
そこで、AI を活用したワークフロー自動化ツールとして、室長である @kanny さんが Dify の導入を、私が n8n の導入をそれぞれ行いました。Dify と n8n はワークフロー自動化ツールとして役割が被る部分もありますが、Dify は Knowledge という形で Vector Store を構築することができ、RAG の構築のしやすさに強みがあります。一方 n8n はより多くのアプリケーションとの連携が可能で、より複雑なワークフローを構築できる点に強みがあります。
私の記憶では、最初に Dify よりも n8n の方が先に社内で流行り始めたと思います。元々、一部のエンジニアが個人的に試していたこともあり、ちゃんと使える社内環境が求められていたこともあります。Slack 上で AI エージェントを動かす例を CPO の @mosa さんが紹介してくれたこともあり、社内で試しに利用してみる人が少しずつ増えていきました。
とはいえ n8n は比較的複雑なツールでもあり、正しく広めていく上では様々な工夫が必要でした。各種サービスと接続するには API キーなどのクレデンシャルが必要で、サービスによって管理者が異なったり、セキュリティ上の懸念をクリアする必要があったり。とりあえずは専用のチャンネルに質問を集約させて、全て適切な部署・人を巻き込みつつ、地道に前に進めていきました。
「こういうことをやるにはどうしたらいい？」といった細かい質問についても、一つ一つ自分で試しながら回答していきました。例えば、「Slack での返答をスレッド内にするにはどうすればいい？」といったものなど。私自身は Slack API を用いたプログラミングも行ってきたので難しくはありませんが、n8n の利用者はそもそもプログラミング経験のない人も多いわけで、Web API 一般の知識を持っているわけでもありません。知識ギャップを把握しつつ、一つ一つ丁寧に解きほぐしていく必要がありました。
プロダクト開発を行っている各事業部では、なんやかんやエンジニアを中心に利用が広がっていきましたが、コーポレート部門では広がり方にギャップがありました。そのギャップを埋めるべく、生成 AI 一般の原則から始まって Dify や n8n の具体的な使い方を解説するワークショップを企画・実施しました。詳しくはコーポレート戦略室の @mako さんの以下の記事に書かれています:
LayerX では毎月、月末の締め会で「ラシトピ」と呼ばれる月刊表彰が行われています。行動指針や羅針盤を体現した人が表彰されるというもので、上半期は基本的に「Bet AI」を体現した人々が中心に表彰されていました。上半期においてはほぼ毎月のように Dify/n8n が絡んだ表彰者が出てきており、合計 9 つもの事例がありました。以下はその一例です:
- AI は人事の相棒になれるか？LayerX に学ぶ、現場ドリブンの LLM 活用
- 営業支援の AI ユーザーは 業務自動運転の夢を見るか？ (AI× 自動化フローで商談量の適正化を超効率化した話)
- 「私が考え、AI が実行する」 AI を相棒にオペレーション組織を立ち上げている話
- 急拡大する営業組織で成果の属人化を防ぐには？"隙間時間"にバクラク「営業 Playbook」を AI 活用で大幅アップデートした話
- 途中に出てくる Alex Mentor という bot は n8n 上に構築されています
- お客様から大量の質問は Slack で"真打エージェント"がお答えいたしましょう
私事ですが、これらの活動が評価され、上半期の全社 MVP にノミネートしていただきました。最終的に MVP は別の方が受賞されましたが、CTO 特別賞をいただくことができました。生成 AI によって世の中が大きく変わろうとしているこの時代、AI に Bet するこの会社のど真ん中で AI に関わる仕事ができていることをとても嬉しく思います。
コーポレートのデータ基盤のために Snowflake を使い始めた
LayerX のバクラク事業部では、2024 頃からデータ基盤の Snowflake への移行を進めています:
プロダクトのために必要なデータ分析には、時にはプロダクトに閉じないこともあります。例えば経営企画などの文脈においては、会計や人事などのコーポレート部門のデータを組み合わせなくては、必要な分析ができないこともあるでしょう。
また、コーポレート部門内の業務においてもデータ基盤のニーズは高まっています。Dify/n8n を使った業務改善の相談を受ける中でも、データがあればできるけどデータがないとできない、というケースは本当に多いです。あるいは、データはちゃんと存在するが、それぞれのデータが散在しているために、必要なデータを集めるのがとにかく大変、というケースもあります。
これらの問題を解決するために、コーポレート部門のデータについても Snowflake に集約していくことにしました。とりあえず試しに会計データを、API を通じて Snowpark から取り込んで個別の事業部に提供したりするところから始めています。
私自身はこれまでデータエンジニアリング的な経験をあまり積んでこなかったため、Snowflake の使い方以前に、OLAP 的なテーブルの設計などの基本的な部分から学んでいく必要があり、何をやるにも手探りの状態です。10 月に入社した @aoshow さんと共に、一緒にダッシュボードを作ったりしながら学んでいます。
他の 2 つに比べるとまだまだ成果に繋げられているとは言い難いですが、それだけに大きな伸び代があると感じています。むしろ、Dify や n8n と組み合わせることで、業務の AI エージェント化を加速させていけるのではと期待しています。
まとめ： 2026 年に向けて
2025 年のコーポレートエンジニアリング室は、プラットフォームという観点で大きく 3 つの軸で進化しました:
- 業務の AI エージェント化: ABAC Generator への AI エージェント組み込みにより、設定ファイル生成の自動化を実現
- AI 活用基盤の民主化: Dify/n8n の導入により、エンジニア以外も含めた全社での AI 活用を推進（上半期だけで 9 つのラシトピ表彰事例）
- データ基盤の礎: Snowflake を活用したコーポレートデータ基盤の構築に着手
これらは単なる個別の取り組みではありません。相互に作用し、加速度的に価値を生み出す関係にあります。AI 活用基盤が広がるほどデータ基盤の重要性が増し、データ基盤が充実するほど AI エージェント化の適用可能範囲が広がります。そして業務の AI エージェント化を進めるには、さらなる AI 活用基盤の改善も必要です。
2026 年もこれらの取り組みを進化させ、LayerX 全体の生産性向上とガバナンス強化の両立に寄与していきます。さらに具体的な話に興味があるぞ、という方はぜひ以下のリンクからお話ししましょう！
