さくらのVPS×Difyでカンタン構築！「現場で回せる」AI契約書レビューシステム ―スタートアップスクリプトで始める専門業務AX―
1. はじめに ChatGPTやClaudeのような汎用的なLLMサービスを業務に取り入れる動きが広がる一方、専門業務の現場で本格活用しようとすると、二つの課題にぶつかります。 一つは「生成AIだけでは業務を完遂できず、 […]
- Dify
- 生成AI
- VPS
Google I/O 2026（+Recapイベント）初参加レポート！
こんにちは、LINEヤフー株式会社の福野です。先月開催されたGoogle I/O 2026に初めて参加してきました。本記事ではそんな初参加者の目線からGoogle I/Oの魅力を紹介するほか、当社で行...
- 生成AI
- Android
DevinからClaude Code Actionsへ ── アカウント管理の自動化基盤を移行した判断とアーキテクチャ
こんにちは。ファインディのPlatform開発チーム（以降、SREチーム）でSREを担当している原（こうじゅん）です。 SREチームでは、AWSのユーザーとGitHubのアカウントの管理をTerraformで運用しています。Slackから申請が来たらTerraformのコードを書き換えてPRを出す、という作業を以前はDevinで自動化していました。 しかしDevinのアカウント利用形態が変わったことをきっかけに、この自動化基盤をClaude Code Actionsへ移行しました。同じようにAIツールでインフラ運用を自動化している方や、Claude Code Actionsの実践的な使い方を探している方に向けて、移行に至った判断理由と、移行後のアーキテクチャについて紹介します。 背景：Devinでアカウント管理を自動化していた 移行を決めた理由 移行後のアーキテクチャ triageジョブ：申請の振り分け routine-prジョブ：ファイル編集とPR作成 escalateジョブ：自動処理できない申請の通知 まとめ 背景：Devinでアカウント管理を自動化していた ファインディでは、GitHub Teamへのメンバー追加やチームの作成・廃止といったアカウント管理を、SREチームがTerraformで運用しています。 エンジニア・ビジネスサイド問わず、メンバーがSlackから申請を出すと、SREがTerraformのコードを手動で書き換えてPRを出し、レビュー・マージ後にapplyされる、という流れでした。毎回決まったパターンのYAML編集とPR作成を手作業でやるのは、典型的なトイルです。 このトイルを減らすために、Devinを使って自動化していました。Slackの申請内容をDevinに渡すと、Terraformリポジトリのコードを編集してPRを作ってくれる仕組みです。この取り組みの詳細は次の記事で紹介しています。 tech.findy.co.jp 移行を決めた理由 きっかけは、2026年4月1日のDevinのアップデートです。このアップデートでDevinアカウントを持たないユーザーはSlackのDevinスレッドに参加できなくなりました。 アカウントを持たない申請者が@Devinに返信してもDevinが反応せず、「動かない」というSREへの問い合わせが増えました。コンプライアンス上、全メンバーへのアカウント一律払い出しも現実的ではありません。そのため、Devinからの移行に踏み切りました。 移行先の選定にあたっては、次の3つを重視しました。 全メンバーが個人アカウントなしで使えること — Anthropic公式の@Claude（Claude in Slack）も検討しましたが、各ユーザーにClaude Codeのアカウントが必要で同じ問題を抱えて断念しました 申請者の体験を変えないこと — Slack Workflowのフォームはそのまま、バックエンドだけを差し替えます チームのツール統一 — 開発チーム全体がすでにClaude中心の開発体制になっており、自動化基盤もそれに合わせました この選定理由より、今回のアーキテクチャとなりました。 移行後のアーキテクチャ 移行後の全体構成は次のとおりです。 flowchart TD subgraph Slack["Slack （申請者の体験）"] F1["メンバー申請"] F2["チーム申請"] Thread[("申請者スレッド")] end subgraph GHA["GitHub Actions"] Triage["triage\n(Claude Code Action)\n整合性チェック・名前解決"] RoutinePR["routine-pr\n(Claude Code Action)\nファイル編集・PR作成"] Escalate["escalate\n自動処理不可を通知"] end SRE["SRE承認・マージ"] Apply["terraform apply"] F1 -->|workflow_dispatch| Triage F2 -->|workflow_dispatch| Triage Triage -->|routine| RoutinePR Triage -->|escalate| Escalate RoutinePR -->|PR作成| SRE RoutinePR -->|受付通知| Thread Escalate -->|エスカレ通知| Thread SRE -->|マージ| Apply Apply -->|完了通知| Thread classDef unchanged fill:#e6f4ea,stroke:#34a853,stroke-width:2px,color:#1b5e20; class F1,F2,Thread unchanged style Slack fill:#f1f8f4,stroke:#34a853,stroke-width:2px; Slack Workflowからの申請がGitHub Actionsのworkflow_dispatchをトリガーし、正常系ではtriageジョブとroutine-prジョブの2つのClaude Code Actionが順に処理する構成です。 ただし、Slack Workflow Builderから直接workflow_dispatchは呼べません。間にSlack Custom Function（Deno Slack SDK）を挟み、GitHub APIへの認証付き呼び出しを行っています。 api.slack.com sequenceDiagram participant WF as Slack Workflow Builder participant CF as Custom Function<br/>(Deno Slack SDK) participant GH as GitHub API WF->>CF: フォーム入力値を渡す CF->>CF: GitHub App秘密鍵でJWT署名 CF->>GH: JWT → Installation Access Token取得 GH-->>CF: Token返却 CF->>GH: workflow_dispatch（Token認証） GH-->>CF: 202 Accepted 申請者から見ればSlackのフォームに入力するという体験は変わっていませんが、裏側ではCustom FunctionがGitHub Appの認証（JWT署名 → Installation Access Token取得）を行い、workflow_dispatchを呼び出しています。 triageジョブ：申請の振り分け 最初のClaude Code Actionは、申請内容の整合性チェックと振り分けを担当します。 チーム名の名前解決（申請者が入力した表記ブレを、リポジトリ上の実際のディレクトリ名に解決する）、申請内容のバリデーション、そしてroutine（自動処理可能）かescalate（自動処理不可）かの判定を行います。 triageとPR作成を1つのジョブにまとめることもできますが、責務と権限を分離するためにあえて分けました。triageジョブは--max-turns 5と少ないターン数に制限し、使えるツールもReadとBash(ls:*)だけに絞っています。判定がおかしければPR作成に進まない安全弁にもなります。 判定結果はJSON Schemaで構造化出力させるので、後続のジョブが確実にパースできます。 claude_args: | --max-turns 5 --allowedTools Read,Bash(ls:*) --json-schema '{"type":"object","properties":{"verdict":{"type":"string","enum":["routine","escalate"]},...}}' routine-prジョブ：ファイル編集とPR作成 triageでroutineと判定された申請は、2つ目のClaude Code Actionが処理します。TerraformリポジトリのYAMLファイルを編集し、ブランチを切ってPRを作成するジョブです。 --max-turns 20とターン数を多めに確保し、ファイル編集やgit操作、PR作成に必要なツールを許可しています。 claude_args: | --max-turns 20 --allowedTools 'Read,Edit,Write,Bash(git checkout:*),Bash(git add:*),...,Bash(gh pr create:*)' PR作成後はSlackの申請スレッドに受付通知を送り、SREがレビュー・マージすればterraform applyが走って完了通知が届きます。 escalateジョブ：自動処理できない申請の通知 triageが自動処理できないと判断した申請は、Slackの申請スレッドにその旨が通知されます。Claude Code Actionは使わず、シェルスクリプトで通知を送るだけのシンプルなジョブです。 まとめ Devinのアカウント利用形態変更をきっかけに、アカウント管理の自動化基盤をClaude Code Actionsへ移行しました。Claude Code Actionをtriage（振り分け）とroutine-pr（PR作成）の2段階に分け、それぞれの責務と権限を絞った設計にしています。 現在、GitHubアカウント管理の移行は完了し、運用を開始しています。今後はAWSのユーザー管理なども移行を進めていきます。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers
- SRE
- Terraform
- GitHub Actions
- 生成AI
Claude Code更新 Fable 5緊急停止・サブエージェント入れ子【6/7〜13】
はじめに サーバーワークスの池田です。 今週（6/7〜6/13）の Claude Code で最も大きな出来事は、6月9日にリリースされたばかりの新モデル Claude Fable 5 が、わずか3日後の6月12日に米政府の指令で緊急停止されたことです。日本のユーザーを含む外国籍者は、現時点で Fable 5 を利用できません。 機能面では、サブエージェントが自分の配下にさらにサブエージェントを生成できるようになり、セッションのタイトルが会話の言語で生成されるようになりました。 対象は v2.1.168 から v2.1.177 までの9バージョンです（v2.1.171 は欠番）。Fable 5…
- 生成AI
- CLI
「Commit to Thailand」——AWS Summit Bangkok 2026 で感じた東南アジアの熱量
こんにちは、サーバーワークス松本です。2026年5月28日に開催された AWS Summit Bangkok 2026 に参加してきました！今回はその様子をレポートします！ バンコクという街 AWS Summit Bangkok 2026 概要 キーノート：AIがイノベーションを加速させる ブースの様子 サーバーワークスとIIJの海外連携について まとめ バンコクという街 タイ国内に足を踏み入れた瞬間に感じたのは、東南アジア独特の蒸し暑さです。 5月末の日本と比べてもかなり湿度が高く、空港で車を待つ30分でしっかり汗をかきました。 到着は夜21時過ぎで道路は空いており、空港からホテルまでは約4…
- AWS
- 生成AI
- クラウド
SSII2026（画像センシングシンポジウム）にスポンサー・登壇しました
Data＆Analysis部の稲葉です。 キャディは2026年6月10日(水)〜12日(金)にパシフィコ横浜で開催されたSSII2026（第32回 画像センシングシンポジウム）にプラチナスポンサーとして協賛しました。また、キャディから3名が登壇しましたので、当日の様子をレポートします。 オーガナイズドセッション：産業界における生成AIの利活用 技術動向解説セッション：CADにおけるAI分野の動向と製造業への実適用 インタラクティブセッション 終わりに オーガナイズドセッション：産業界における生成AIの利活用 生成AIが産業界でどのように価値を生み、どのような条件で実運用に乗るのかを議論するセッションです。 キャディからは、オーガナイザーとしてシニアリサーチエンジニアの福原（@gatheluck）、また講演者として私、稲葉（@mi_spindel）が登壇しました。会場には約450名と、非常に多くの方にお越しいただきました。 登壇資料はこちらです。 speakerdeck.com speakerdeck.com 私からは、Data＆Analysis部として取り組んでいる生成AI活用事例として製造業RAGを紹介しました。 （本当は、他にも様々な取り組みがあるのですが、また機会を見て紹介したいと思います。） また、この中で直面した課題の一つが「各LLM/VLMモデルが我々のドメイン特有のタスクをどこまで実行できているかが不明」というものでした。 そこで、製造業LLM/VLMベンチマークとしてManuDraw-Benchを独自構築し、比較評価したお話しをしました。 皆様からのたくさんの質問をいただきまして、ありがとうございます。当日は時間の関係で回答しきれませんでしたので、ここで回答したいと思います。 Question： CADでのDXFはパースせずに図面の見た目で拾ってしまった方が総合的なコストが安いという判断でしょうか？ Answer：DXFなどベクター図面のまま処理した方が、QualityやCostの観点で良いタスクは存在していると思います。ただ、結局はimage encoderが必要なタスクはありますし、処理プロセスの種類が増えることによって運用負荷も増えますので、QCDを総合的に判断して技術選定をしています。 Question：会社の固有知識については基本的にはRAGで対応となると思うのですが、RAGでは対応しきれないのではないか、モデルの Fine Tuning が必要ではないかという意見も社内であり、意見が分かれています。 Fine Tuning まで実施したというような事例はあるでしょうか？ Answer：Fine Tuningまで実施した事例があるかないかの詳細はお答えできないのですが、Fine Tuningを考える前に基本はナレッジ管理とGroundingで対応できないかを先に考えるべきだと思っています。また、Fine Tuningと言えど一定のデータ量は確保しなければならないですが、機密情報の漏洩を考えると個社ごとに調整をすることになりがちです。確保できるデータ量とその労力に対する効果を検討する必要があります。 Question：過去の故障事例などは、設計改善に使用可能なレベルで、原因情報が現場から上がってくるモノでしょうか？実は、原因をLLMが把握するところに課題はないでしょうか。 Answer：おっしゃる通りで原因とその対応が上がってくる仕組みを作ることが重要ですし、そこは課題です。その解決のためにも、キャディが提供しているような部横断のデータ基盤を構築しデータを紐づけることが必要になります。 Question：P15のVLMによる3次元点群予測は1点1点を文字列として出力しているわけではないのだと思いますが、Pythonスクリプト出力などでCADモデリングさせて、表面に点を生やしているのでしょうか？ Answer：1点1点を点群を文字列として出力させているのではなく、メッシュモデルとして形状を面の組み合わせで出力させてから点群サンプリングをしています。おっしゃるようにPythonスクリプト出力などでCADモデリングする方法もありますが、コーディング能力や各LLM/VLMが扱える開発環境にも依存するため、このような方法を取っています。 Question：位置やサイズなど幾何的な理解の性能は、モデルの進化を待てばある程度上がってきそうなベンチの結果になっているのでしょうか？ Answer：そのあたりは今後の傾向を見てみないと何とも言えないところですので、今後もトラッキングしていきます。ただ、自然画像や文字列で表現されている位置やサイズの理解は進化が見られます。 Question：3面図とアイソメ図でVLMからみた理解度にどれだけ差があるのでしょうか？VLMの訓練にメインで使われているであろう写真データには三面図的な見え方は珍しそうに思います。写真に近そうなアイソメ図の方が理解してくれたりするのでしょうか？ Answer：とても良いご指摘です。三面図をそのまま与えるよりは、斜めから見たアイソメ図の方が形状の理解力は高い印象です。ただ、アイソメ図には寸法など必要な情報が抜けているので、処理プロセスのどこかでアイソメ図にリフトするとかデータを組み合わせて利用するとか工夫は必要にはなると考えています。 共に登壇いただいたエクサウィザーズの加藤様、LayerXの松村様、素晴らしい発表をありがとうございました。エクサウィザーズ様はやはり取り組まれていることの幅が広いですし、生成AIの性能だけでなくUI/UXやガバナンスといった活用推進の重要なポイントを俯瞰して抑えられているなと感じました。LayerX様はAgentありきの業務フローに変革していく強い意思を伝えながらも、結局は当たり前をやりきれるかという話に共感しました。 登壇の様子 技術動向解説セッション：CADにおけるAI分野の動向と製造業への実適用 昨今の3D基盤モデルなどの潮流を概観し、CAD解析技術の実プロダクト適用における「研究と実践」のリアルを解説するセッションです。 キャディから、Data Platform本部長の今井（@imaimai0）が登壇しました。こちらも500名近い方に聴講いただくことができました。 speakerdeck.com なぜ製造業においてCADが重要なのか、CADの活用において何がボトルネックになっているのか、最新研究の動向はどうなっているのかをお話ししています。 詳細は資料をご確認いただけると幸いですが、私からは特に、CAD（Geometric系）やMechanical Engineering系の研究開発をもっと盛り上げたいと思っていることをお伝えしたいです。 資料の中でもCVPRにおいてGeometric系の論文は5%程度というお話しがありましたが、製造業のGDPが日本の2割程度を占める巨大産業にも関わらず日本においても類似の研究開発が少ないように思います。我々もResearchチームの規模を拡大中ですし、共同開発や共同研究の機会も探しているところです。一緒に盛り上げていただける仲間を募集中です。 インタラクティブセッション 6/11（木）のブース出展では、多くの方にキャディブースへお越しいただきました。セッションを聴講して「話を聞いてみたい」と立ち寄ってくださった方もいらっしゃいました。 ポスター発表では、現在取り組んでいる研究開発テーマを紹介しました。注力しているテーマとして、以下の3点をご紹介しました。 設計資産全体を横断して検索するための、2D図面と3D CADモデルの埋め込み空間の統合 3D CADデータ内の加工に必要な特徴の認識 製造業ドメインに特化した独自の視覚言語モデル（VLM）評価ベンチマーク ManuDraw-Bench ManuDraw-Benchは公開されているのか？されないのか？といった質問をたくさんいただきましたが、権利の関係上公開は難しいです。ただ、業界の研究開発を促進したいと思っていますので、何かしら対応を考えていきたいとは思っています。 お話いただいた皆様、本当にありがとうございました！ 終わりに SSII2026への協賛・参加を通じて、製造業領域におけるAIの研究開発の現状や、その中でのキャディのチャレンジについて知っていただく貴重な機会となりました。また、来場者の方との交流から、日々取り組む課題に対してもヒントを得られる非常に有意義な場でした。 運営の皆様、素晴らしい会をありがとうございました。 今後もキャディは技術的な挑戦を続け、画像センシング・コンピュータビジョン研究コミュニティの発展と、モノづくり産業のポテンシャル解放の両面に貢献していきたいと思っています。 また皆さんとお会いできることを楽しみにしています！
- 生成AI
- LLM
- CAD
人工知能学会全国大会（第40回）にシルバースポンサーとして協賛、研究発表を行いました！
SmartHRのML（機械学習）エンジニアの井上です。 SmartHRは2026年6月8日〜12日に群馬・高崎のGメッセ群馬で開催された「2026年度 人工知能学会全国大会（第40回）（JSAI2026）」にシルバースポンサーとして協賛、および研究発表を1件行いました。 現地組・リモート組を合わせて複数のメンバーが参加し、「うちのプロダクトに使えるのでは？」と大盛り上がりの5日間でした！ 人工知能学会全国大会とは 人工知能学会全国大会は、AI技術に関する国内最大の学会です。 機械学習の基礎・応用研究から産業応用まで幅広い発表が集まり、AIの最新動向を把握できる機会として毎年多くの参加者が集まっています。 今回の第40回大会は40周年にあたる節目の大会で、約5000人の参加者が集まりました！ 人工知能学会全国大会（第40回） 今年の研究トレンドの変化 JSAI2026の全発表タイトルをキーワードで分析し、昨年の傾向と比較したところ、興味深い傾向が見えてきました！ 技術テーマ出現頻度ランキングの変化（JSAI2025→JSAI2026） 発表の出現頻度をもとにランキングをスロープチャートで比較すると、「LLM・基盤モデル」「AIエージェント」「対話・会話AI」の上位3テーマは今年も順位変動がなく、この領域が引き続き学会全体の中心軸であることが確認できました。 一方で最大の急上昇は「生成AI」で、19位から7位へと12ランク上昇、「ロボット・フィジカルAI」も13位から6位へ7ランク浮上しており、フィジカルAIへの関心が学術研究の領域にも着実に波及していることがうかがえます。 最大の急上昇を見せた「生成AI」も、発表の内容は多岐にわたっていました。生成AI自体を技術として扱う研究だけでなく、keep4o を代表とする生成AIをめぐる人間・社会の動きの考察、生成AIを要素技術として活用したシミュレーション研究、プロダクト活用の実践知を共有する発表も増えており、生成AIが「研究する技術」から「社会に埋め込まれた前提」へと変わりつつあることを実感しました。 SmartHRからの発表 SmartHRからは1件の機械学習領域における口頭発表を行いました！ 敵対生成プロンプト同時探索による内省型プロンプト最適化 発表者: 井上 耕太朗 セッション: 4M5-GS-2f-05（6/11 16:30-16:45） LLMアプリケーションのプロンプト最適化に関する研究です。SmartHRでは RAG を活用した AI アシスタントなど様々な LLM アプリケーションを提供していますが、これらをローンチ前から高品質な状態に保つには、プロンプトを事前に検証・改善しておくことが重要です。しかし従来のプロンプト最適化手法の多くは大量のラベル付きデータを前提としており、ローンチ前の段階では活用しにくいという問題がありました。 今回の研究ではこの課題に取り組み、目的タスクを正しく解くプロンプトと、目的タスクを欺くための敵対的な生成プロンプトを同時に育てる手法「Adversarial GEPA」を提案しました。ラベル付きサンプルがわずか4〜8件という少数データの設定においても、既存手法（GEPA）を上回るプロンプト改善を実現しています。 発表をする井上 発表に使用したスライドは Speaker Deck で公開しています。 speakerdeck.com We Are Hiring! SmartHRでは最新技術に明るいメンバーが集まった環境で、革新的なAIプロダクトづくりに取り組んでいます。 ぜひ一度SmartHRのAIチームにご興味をお持ちの方へをご覧いただき、お気軽にお問い合わせください！ tech.smarthr.jp
- 生成AI
- LLM
- 機械学習
Build First, Discuss Later｜初回ミーティングに動くプロトタイプを持ち込んだら、意思決定が爆速になった
こんにちは、メルペイiOSエンジニアのkubomiです。 この記事は Merpay & Mercoin Tech Openness Month 2026 の 10日目の記事です。 生成AIによって、エンジニアが短時間でプロトタイプをつくれる場面はかなり増えました。最近、小規模なプロジェクトで「初回ミーティングの前に、動くものをつくり切ってしまう」という進め方を試したところ、意思決定のスピードが劇的に変わりました。私はこのやり方を "Build First, Discuss Later（まずつくる、議論は後）”と呼んでいます。この記事では、その具体的な進め方と、実践を通じて私自身に起きたマインドセットの変化を紹介します。 よくある開発フローと、その課題 私たちの現場では、開発に取りかかる前に、まず関係者の認識をそろえておくのが一般的です。具体的には、最初にプロダクトマネージャー（PdM）が大まかな仕様を用意し、それをもとにキックオフミーティングを開いて詳細を議論します。議論を経てPdMが仕様を固め、エンジニアはその仕様をもとに見積もりを出して実装に入ります。 ただ、議論して仕様を固めたつもりでも、いざつくり始めると「あれ、ここの挙動どうするんだっけ？」という疑問が次々と出てくることがあります。そのたびにPdMへ確認したり、追加のミーティングを開いたりすると、少しずつコミュニケーションの往復が増えていきます。 "Build First, Discuss Later" という提案 そこで私が実践したのが、プロセスの順番をあえて逆転させる "Build First, Discuss Later" です。仕様が固まる前に、まず動くプロトタイプをつくってしまうという発想で、ミーティングはその動くものを土台に議論を進めます。 従来は「議論して仕様を固めてからつくる」流れでしたが、これを「先につくり、その動くものを見ながら議論する」へと入れ替えます。実際に触れる画面があると、抽象的な仕様書をめぐる議論よりもはるかに早く、関係者の認識がそろっていきます。 ただし、何にでもこの進め方を使うわけではありません。何日もかかるような大きな実装でこれをやると、方針が変わったときの手戻りが大きすぎます。私の場合は、数時間から1日以内でつくれるくらいの小規模な施策に限定しています。そのくらいの規模なら、悩んで待つより、とりあえずつくってしまったほうが圧倒的に速い、という実感があります。 ミーティングにプロトタイプを持ち込む3つのステップ 私は "Build First, Discuss Later" を、ミーティングの前・中・後という3つの場面に分けて実践しています。ここでは、アプリの画面にバナーを追加した事例を例に、それぞれの場面で意識していることを順に紹介します。 ミーティング前：自分のベスト案でつくり切る ミーティング前は、手に入る計画書や仕様書をAIと一緒に読み込み、「なぜつくるのか（Why）」「何をつくるのか（What）」を自分なりに解釈します。この段階で最も大事なのは、完璧な実装をつくることではなく、どこが曖昧なのかを目に見える形にすることだと考えています。実際、詳細が決まっていないことがほとんどですが、曖昧な点にぶつかっても立ち止まりません。PdMに質問する代わりに、いったん自分が考えるベストな案でつくり切り、迷ったポイントはミーティングのアジェンダに整理しておきます。 たとえば、バナー追加の事例では、リリースに必要な最小限の機能に絞って早くリリースするか、将来使い回せる再利用性を優先するか迷いながらも、まず最小限の機能で動くプロトタイプをつくりました。UIデザインがまだない場合も、既存の画面部品を組み合わせた仮の見た目で形にしました。 ミーティング中：動くものを見ながら論点を解消する ミーティング中は、その動くプロトタイプを見せながら議論し、可能な限りその場で論点を解消します。意見が分かれそうな箇所には、あらかじめA案とB案を用意し、「私はこういう理由でA案を推します」と推奨案まで添えておきます。バナーの例では、期日を踏まえて、リリースに必要な機能に絞った設計プランと、将来の再利用まで見据えた設計プランを提示し、PdMはその場で前者のプランに合意できました。細かな仕様も、プロトタイプを見ながらサクサクと決まっていきました。判断の材料がそろっているため、議論は驚くほど早く前に進みます。 ミーティング後：決まった内容をすぐ反映する ミーティング後は、決まった内容を仕様書に反映し、実装を微修正したうえで品質保証（QA）のテストに回します。大きなつくり直しが起きにくく、初回ミーティングの直後にはリリースが見えている、という状態になりました。バナーの例では、私がつくった仮の見た目をデザイナーが本番デザインへブラッシュアップし、実装側はそれを反映する微修正で済みました。 "Build First, Discuss Later" で起きた3つの変化 この進め方を試してみると、ミーティングの進み方やPdMとのやり取りがかなり変わりました。特に大きかった変化は、次の3つです。 1つ目は、ミーティングがほぼ1回で完結するようになったことです。うまくいけば、初回ミーティングが終わった時点で仕様も実装もほぼ固まっており、開発見積もりすら不要になることもあります。その後の往復も大きく減りました。 2つ目は、議論が速く、かつ正確になったことです。実際に動くものを見せながら「この画面の挙動はこれでよいですか」と確認できるため、言葉だけのやり取りで生じがちな認識のズレが起きにくくなりました。 3つ目は、PdMの負担が軽くなったことです。エンジニアが具体的な仕様の案まで持っていくので、PdMは方針を確認するだけで済みます。特にPdMが複数プロジェクトを兼務しているような状況では、その確認コストを減らせるだけでも大きな価値があります。 「待つエンジニア」から「提案するエンジニア」へ こうした変化は、単に開発プロセスやコミュニケーションを効率化しただけでなく、私自身のエンジニアとしてのマインドセットにも影響を与えました。 以前の私は、決まった要件を正しく実装することがエンジニアの主な役割だと思っていました。けれど、PdMが持つWhyと大まかなWhatを起点に、まず動くものをつくってみると、「これは要らないかもしれない」「こっちの方がお客さまに価値を届けられるのでは」といった議論を、自分から持ち込めるようになりました。 いちばん大きかったのは、「私はこれがいいと思う」というアイデアを持ってミーティングに参加できるようになったことです。ただ仕様を待つのではなく、要件定義の段階から意見を出し、仕様を決めていく側に少しずつ入っていけるようになりました。 そうやって関わっていると、「この機能は今いちばん自分が詳しい」というオーナーシップも自然と生まれてきます。自分の提案が仕様に反映され、動くものを通じてプロダクトの方向性が決まっていく。その過程に関われるようになって、プロダクトづくりが前より一層楽しくなりました。 生成AIによって「まずつくってみる」ハードルが下がったことで、エンジニアが上流の議論に入りやすくなったと感じています。プロトタイプをつくってミーティングに持ち込むことは、単に開発を速くするだけではなく、エンジニアがより主体的にプロダクトづくりに関わるためのきっかけにもなるのだと思います。 まとめ "Build First, Discuss Later" は、先に動くプロトタイプをつくり、それを見ながら議論することで、意思決定を速くする進め方です。みなさまも、「仕様待ちで開発が始められない」「仕様が曖昧で手戻りが多い」と感じたら、自分なりのプロトタイプを会議に持ち込んでみてください。会話が前に進むだけでなく、プロダクトづくりの楽しさも少し違って見えてくると思います。 次の記事は mewutoさんです。引き続きお楽しみください。
- 生成AI
- プロトタイピング
- プロダクトマネジメント
Coding Agentの時代: ソフトウェアエンジニアの未来
社内 IT の部署であるGYOMUハックでマネージャーをやっている kumataro です。私たちの取り組みから実感している次の時代のソフトウェアエンジニア像のひとつについて書いてみました。 2025年から2026年にかけて、Coding Agent が爆発的に進化しました。Claude Code や Codex、GitHub Copilot Agent など、コードを書くだけならAIが人間よりも高速かつ正確にこなせる時代が現実のものになりつつあります。 最近は、自分で1行もコードを書いていないという話も聞くようになってきました。 そんな環境ですので「AIに仕事を奪われるのではないか」という不安を抱いているソフトウェアエンジニアの方も多いのではないでしょうか。 「コードを書くことそのもの」に強いやりがいを感じているエンジニアにとっては、大きな変化に戸惑う側面もあるかもしれません。しかし「課題を解決すること」が目的であるエンジニアにとって、AI はこれ以上ない強力な武器です。私たちはこの変化を、エンジニアという職種がより本質的な価値へと回帰するチャンスだと捉えています。 Coding Agent 時代に陥りやすい罠 私たちは社内のバックオフィスの生産性を向上させるためのエンジニアチームです。Claude Code を用い、実装の速度が増したことにより、寄せられる要望に対応できる能力も高まっています。 同時に、ここには罠が存在することにも気づきました。それは、開発速度が増したことにより、寄せられた要望に素早く対応するだけの存在に陥ってしまいやすいということです。対応は感謝されるだけに、すぐに要望を実現したい気持ちはエンジニアにとっても、とても強いものです。 しかし、この先に待ち受けているのは、部門、業務ごとに個別最適化された処理やデータの乱立です。一見、業務は最適化されているように見えますが、全体的な視点では業務の重複による一貫性のなさや、データの散在が起こり、連携が困難な状況が急速に拡大するのが目に見えています。 実際に freee のバックオフィス内でも、従業員数の予測値について、労務と社内IT、財務の間でそれぞれの課題感から別々に算出している事例がありました。このような組織横断的な不整合の解決は個別の部署の業務改善では実現できません。 こうした「部分最適の罠」を回避し、AI を真の武器として活かすためには、単なる「対応力」を超えた、より戦略的なアプローチが不可欠です。そこで私たちが今改めて立ち返ったのが BPR と FDE というふたつのキーワードです。 道を切り開くふたつのキーワード、BPR と FDE BPR（Business Process Re-engineering）: 既存の業務プロセスをそのままシステム化するのではなく、プロセスそのものを根本から再設計すること。 FDE（Forward Deployed Engineer）: 本社のオフィスで仕様調整を待つのではなく、現場に入り込み、業務を観察し、課題を発見し、動くものを作って解決する「前線配備エンジニア」。 FDE は米国 Palantir 社などが先駆けて導入し有名になったポジションですが、これが「今の時代」に特にもてはやされているのには、明確な技術的・ビジネス的な背景があります。 freee でも社内のバックオフィスでは、ドッグフーディング的に自社プロダクトを利用しています。そういった環境での業務改善において、パッケージ化された SaaS をそのまま導入するだけでは解決できない企業固有の複雑な課題は残るのが現実です。 SaaS のデータと社内独自のデータの統合: 業務活動ではデータ分析の要求は常にあります。しかし、SaaS 内のデータと SaaS 外のデータを統合して扱うのは簡単なことではありません。また同じ元データのはずのものが部署毎の処理の中で異なる数字になって出てくることもあります。 スピード感: フィードバックは SaaS プロダクトに届けることができます。しかし、開発優先度の問題や SaaS としての全体最適化の中で、対応スピードは思うように上がりません。 個別最適化: SaaS という性質上、個社別の環境に最適化するわけには行かないため、個別の事情にピッタリマッチする改善はできないのが現実です。 こういった課題に対して、FDE は現場で活動している強みで、自ら解決策を提示し、導入、運用まで進めることができる役割となっています。 私たちのチームは社内における FDE として、業務をハックするエンジニアチームです。私たちが取り組んでいるのは、まさにこの FDE の動きを通じた BPR の実践です。 ミッションとバリュー では、ふたつのキーワードと陥りやすい罠を避けるために、どのようなマインドセットを持って業務に取り組めば良いと考えているのか紹介してみます。 私たちのミッションは「テクノロジーと対話を通じて、バックオフィスの生産性を最大化し、全従業員がより創造的な業務に集中できる環境を創り出す」ことです。このミッションを実現するために、以下の4つのバリューを大切にしています。 Why First（なぜ？から始める） 私たちは、表面的な要望の奥にある本質的な課題を探求することを常に最優先します。依頼された解決策をそのまま実装するのではなく「その業務はそもそも必要なのか？」「理想の状態は何か？」という問いから始めます。必要であれば「開発しない（業務自体をなくす）」という選択すら積極的に行います。 Be a Partner（最高のパートナーであれ） 私たちは、依頼者を「お客様」ではなく「課題解決のパートナー」と捉え、共に考え、共に成功を目指します。依頼者と対話し、業務のAs-Is/To-Beを描きながら、現場の泥臭い課題を共に解きほぐしていきます。 Impact Driven（インパクトで動く） 私たちは、取り組むべき改善を、そのインパクト（効果）の大きさによって判断します。 Go Simple（シンプルを追求する） 私たちは、複雑な問題を、誰もが使い続けられるシンプルで持続可能な解決策へと導きます。 私たちが目指すシステム全体像 こういった理想を実現するため、現場の課題に寄り添いながら、同時にそれを支える強固な技術基盤も並行して構築しています。現在、私たちが構築しているシステム全体のイメージ図を共有します。 開発中の基盤の全体像 Cadiz: OneLogin × AWS Cognito × Cerbosを組み合わせ、行・列レベルの認可制御を一元化した社内アプリ開発基盤。社内業務で用いる社員のセンシティブなデータも適切に守る。 Service Data Pipeline: AWS EKS 上で構築した自前のデータ連携基盤。複数の SaaS やデータソース間を柔軟に連携。 データ分析基盤: Google Cloud（BigQuery）/ Looker Cloud Core / Looker Studio Pro で構築したバックオフィスデータマネジメントを支えるデータ活用基盤。局所最適化された自動化でデータの分断が起こらないように一元化。 これらは単なるツールではなく、バックオフィスという複雑な領域を、他社にも誇れる「ショーケース」に変えるための重要なパーツです。これらの技術選定の裏側や、なぜその構成を選んだのかというトレードオフについても、また別の機会に詳しく共有していきたいと考えています。 まだまだ道半ば ここまで「FDE 的な動き」や「強固な基盤」について書いてきましたが、正直に言えば私たちはまだ、目的を成し遂げるための努力が必要な「発展途上」の段階です。 バックオフィスの現場には、未解決の複雑な業務フローや、解決すべきレガシーな仕組みが山ほど残っています。しかし、だからこそ面白い。 完成されたシステムを保守するのではなく、業務の現場に深く入り込み、技術の力で泥臭い課題を一つずつ解きほぐし、組織のあり方そのものを変えていく。この「変化のプロセス」こそが、私たちがエンジニアリングを通じて体験できる最大の醍醐味です。 これらの状況は、程度の差こそあれ、どのような会社にも存在するものではないでしょうか。 Coding Agent が強力になる中で、これからのエンジニアに必要なスキルセットは現場の深い理解（ドメイン知識）と、それを技術で最適化するアーキテクチャ設計能力の掛け合わせではないか、というのをひとつの答えとして提示してみました。 最後に GYOMUハックは、AIを武器に変え、バックオフィスの「前線」で挑戦を続ける仲間を募集しています。 「技術を使って組織を強くしたい」「コードを書く以上に、本質的な課題解決をしたい」と考えているエンジニアの方、ぜひ私たちと一緒にバックオフィスの新しいあり方を創りませんか？ hire.wantedly.com
- 生成AI
- アーキテクチャ
- AWS
- Google Cloud
そのAI活用、実は「あの人頼み」になっていませんか? ― Amazon Quickで、AIを「個人技」から「チームの仕組み」へ
クロスインダストリー第一本部の渡部です。 最近はAIの普及により、業務が大きく効率化されてきました。「もうAIが無いと仕事にならない」という方も多いのではないでしょうか。 そんな中で、こんな声を耳にすることがあります。 「AIを使えば、誰でも質の高いアウトプットが出せる」 「AIを使えば、業務の属人性は排除できる」 果たして、本当にそうでしょうか。 私はむしろ、「AIの活用の仕方そのもの」に新たな属人性が生まれていると感じています。同じツールを使っているはずなのに、人によってアウトプットの質が大きく違う。その差は、次の2つから生まれます。 AIにどんなデータを読み込ませるか（データの属人性） …
- 生成AI
- AWS
Code w/ Claude Extended | Tokyo 参加レポート
ファインディの森（@jiskanulo）と西村（@sontixyou）です。 2026年6月11日に開催されたAnthropic主催のイベント「Code w/ Claude: Extended | Tokyo」に終日参加してきました。 claude.com 本記事はその参加レポートです。私たちがセッションを聴いてどう感じたか、セッションの内容をどう活かすかの感想も書いていきます。 Workshopで気になったセッション How we Claude Code Ship your first Managed Agent ドメインエキスパートがソフトウェアを作る What happens when domain experts can finally build The 1% problem: How domain expertise + Claude let a 2-person team hit #1 on a global classification benchmark まとめ ファインディでは一緒に働く仲間を募集しています Workshopで気になったセッション 西村は主にAnthropicメンバーによるWorkshopへ参加しました。Anthropicが取り入れている設定や仕組みを弊社のプロダクト開発フローに適用できるかを意識して聴きました。 How we Claude Code claude.com Anthropicメンバーが実際に使っているClaude Codeのセットアップ方法を紹介するものです。 今回のイベントでのワークショップで説明された題材は次のリポジトリで公開されています。 github.com このセッションで最も印象に残ったのは「徹底インタビュー」と「HTML先行プロトタイプ」の2つです。 「徹底インタビュー」では、Claude Codeにインタビュアー役を担わせて要件を引き出します。 インタビューでは、つぎのインタビュープロンプトをClaude Codeに渡して、HTMLのプロトタイプを作るための要件を引き出す設計になっていました。 I want to build a bill-splitting app, can you help me brainstorm with me on who the audience is, and then interview me in-depth using the AskUserQuestion tool about what to build, focusing on pulling out any ambiguities to create a spec. 上記のプロンプトを実行し、Claude Codeとのやりとりを通して、要件の曖昧さを潰していき、SPEC.mdを作成する流れが紹介されました。要件の曖昧さを上流で潰すことで、実装のやり直しを減らすという設計思想です。 つぎに「HTML先行プロトタイプ」ではSPEC.mdをもとに、4つの異なるデザインを提案させて、HTMLのプロトタイプを作る流れが紹介されました。 Read ../phase-1-planning for its spec file, then help me figure out the overall design of this app. Explore 4 different designs, and create a set of HTML files with important screens for each. 上記のプロンプトを実行すると、つぎのHTMLのプロトタイプが出力されました。 Markdown形式でデザイン仕様を書き出すのではなく、クリックできるHTMLのプロトタイプを出力することで、見た瞬間に判断できます。 設計するタイミングで、Claude Codeとの認識合わせが視覚的にできることで、実装フェーズでのやり直しが少なくなり、トークン使用量の削減につながります。 また、既に運用しているサービスではデザインシステムといったデザイン基盤があれば、精度よくHTMLを出力できる可能性があります。それによって、新しい機能のデザインをするときの認識合わせがスムーズになりそうだと思いました。 Ship your first Managed Agent claude.com Claude Managed Agents（CMA）の全体像を、インシデントレスポンスのデモを通して整理するワークショップです。 このセッションで印象に残ったスライドが「The brain left the box」でした。 以前のアーキテクチャは、Agent loopとTool executionが同じコンテナの中に同居していました。Managed AgentsではAnthropicが管理する1つのサービスとして動き、ツール実行のSandboxはツールが必要なときだけオンデマンドで起動します。クライアントが切断されていてもループは動き続けるため、ローカルのターミナルを閉じてもセッションが止まりません。 これまで西村の開発環境のClaude Codeの使い方では、ローカルPCでClaude Codeを稼働させているため、プロンプトを入力しないとAIエージェントが動き出せませんでした。また、並列セッション数も最大8が限界でした。 Managed Agentsはこの2点を変えられると感じました。オンデマンドで非同期で動き続ける実行環境があれば、人間の合図を待たずに実装する用途が一気に現実的になります。 試したい用途として思い浮かんだのは、着手できていないイシューの開発・リファクタリング、そして人間が介在せずにPRをマージすることです。 最後の「自律マージ」には前提条件を考えなくてはいけません。最低限必要な前提条件を決めておかなければなりません。 例えば、テストカバレッジが一定基準を超えていること、テストの堅牢性が担保されていることなどです。 これらの前提条件を満たすための仕組みを整えることが、AIエージェントによる自律マージの実現に向けた重要なステップになると感じました。 ドメインエキスパートがソフトウェアを作る 森はFounder stageを中心に話を聞いていました。 いずれのセッションもドメインエキスパートの知識・決定が重要であることを話されていました。 いくつかご紹介します。 What happens when domain experts can finally build claude.com 登壇はクイーンズランド大学のJason Tangen教授。AIネイティブ時代のプロダクトは、汎用的な人材ではなく深いドメイン知識を持つ個人から生まれるという主張です。 「去年までソフトウェアを一行も書いたことがなかった」という彼が、6ヶ月で3つの本番アプリをデプロイしました。 登場したアプリはいずれも学生向けのもので、シラバス生成ツール（classbuild.ai）、法廷証言トレーニング（crosscoach.ai）、学生向け説明ツール、学生の顔と名前を覚えるゲームなど。 専門家の頭の中に眠っていたアイデアが、AIにより作るコストが下がり具現化できるようになりました。 最後に聴衆へ「あなたが何年も密かに欲しいと思っていた小さなツールは何ですか？」「チームの中で、実際にその仕事をやり続けてきた人は誰ですか？」と問いかけられました。 コードを書く能力ではなく、「何を作るべきか」を知っていることが大切なのだと感じました。 The 1% problem: How domain expertise + Claude let a 2-person team hit #1 on a global classification benchmark claude.com 登壇者はGahee Seo氏。分類の誤りが金銭的損失に直結する貿易コンプライアンス領域で、ドメイン知識とClaudeの組み合わせが基盤モデル単体を超える優位を生むことを示します。 韓国からEUへの輸送など、さまざまな規制が複雑に絡み合う貿易の領域では、どんなAIモデルを使うかよりも専門家の判断フローをどう再現するかが優位を決めるとのことです。 最初のプロトタイプはSingle agentで1件の分類に6分かかっており、また、アウトプット精度にも課題があったとのことです。 課題を解決するために分類器を新しく訓練するのではなく、専門家が5段階で判断するワークフローを複製したという設計思想を発表してくれました。 入力が曖昧なまま処理が走らないようinput gateを設けたこと 全規制ルールをsystem promptに詰め込む設計をやめ、必要な文書を検索する Retrieval と出力結果を検証する Verifierという構想に転換 これらの対応をとりあげていました。さらにエージェントを役割ごとに分割することで30秒まで短縮しました。 アウトプットではなくワークフローを教える、という発言もありました。 期待する出力形式を示すのではなく、専門家がどういう順番で何を見て判断するかをシステム化する。職人芸をインフラに変える、という表現が使われていました。 まとめ 西村が午前に参加したAnthropicのワークショップ2つには、共通した問いがありました。 How we Claude CodeのHTMLプロトタイプは、実装前に人間の判断を前の工程に集約する仕組みです。Ship your first Managed Agentの非同期実行は、後工程での人間の介在を手放すための基盤です。 方向は逆に見えますが、根底にある問いは同じだと感じました。「人間はどこで関与すべきか」を先に設計する、という考え方です。その2点を組み合わせることで初めて、AIと人間の役割分担がきちんと設計できると思いました。 森の参加したセッションは「個人開発者・アーリーステージな創設者向け」という性格のものが多かったです。個人が専門知識を武器にプロダクトを作る事例が多く、それ自体は示唆に富んでいました。 どのセッションでも専門家の知識、決定が大事であるという主張を別の角度から語っていました。 一方で、チームでどう使っていくか・チームの中でどう成長していくかという話はありませんでした。 最近個人的に悶々としている「専門家がいない領域でどう専門性を担保するか」「専門家をどう育てるか、時間をかけるしかないのか」という問いには答えが見つからなかったので引き続き考え続けます。 ファインディでは一緒に働く仲間を募集しています ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 <iframe src="https://hatenablog-pa
- 生成AI
- Claude
エンジニアミートアップのはじめかた
技術情報のキャッチアップは、業務が忙しくなると最初に削られます。意志の問題ではなく、情報収集が時間を細かく、けれど継続的に消費する活動だからだと思っています。newmoでは立派な仕組みを作るより、忙しい週でも続く軽いものとしてエンジニアミートアップを行なっています。 Engineering Meetup とは newmoには「Engineering Meetup」という場があります。週に一度、エンジニアリングに興味のあるメンバーが話題を持ち寄る1時間のランダムトークです。毎週金曜の夕方に、所属や雇用形態を問わず誰でも参加できます。テーマはWebでもモバイルでもクラウドでも自動運転でも、最近読んで面白かった本でもよく、「newmoのここに困っている」といった仕事の話も歓迎です。 コンセプトは「準備を頑張らずにゆるく話す」。資料は作らず、話したいテーマをNotionに書いて当日集まって話します。参加は強制せず、忙しい週は欠席でも、耳だけのラジオ参加でもよく、最低2人集まれば開きます。 モチベーション 一人で技術の変化を追い続けるのには、限界があります。割ける時間と注意が有限だからです。だったら一人で抱えるより、チーム全員が薄くアンテナを張って持ち寄るほうが、広く拾えます。持ち寄って話すこと自体が、お互いの興味や困りごとを知る機会にもなります。そして拾ったものを読んで終わりにせず、自分たちのコードや仕事へつなげたい。このやり方は、負荷を分担すること、消費で終わらせないこと、お互いを知ることのために続けています。 やっていること エンジニアミートアップをやるには何かしらの話すネタ集めが必要です。 ネタ集めの仕組み自体は目新しくありません。Slackで気になったメッセージ（記事、リリースノート、インシデント、誰かの登壇やブログ）に、専用の絵文字（:meetup_neta:）を押します。するとReacji Channelerが、それをネタ帳チャンネル（#nm-dev-meetup）へ自動で集めてくれます。 engineer-meetup 肝心なのは、投稿し直す手間がないことです。読んでいる場所でスタンプを押すだけなので、忙しい週でも止まりません。 絵文字はあえて1種類にしています。「紹介したい」「聞きたい」と意図で分けたくなりますが、分けると押す前に迷いが生まれ、その一瞬が手を止めます。信号は「気になった」の一点でいい。分類は、後で人が話すときにやれば足ります。 週に一度、溜まったネタをClaude Coworkに渡し、古い順に要約してNotionのmeetupページにまとめさせます。各ネタはSlackやNotionを検索させて背景を補わせます。これがその週のアジェンダになり、あとは毎週の定例でそれを見ながら話します。 Coworkでスケジュール実行しているプロンプトもすごく単純です。 Notionの「Engineering Meetup」の今日のmeetupページにネタを古い順でまとめてください。 * Slackの#nm-dev-meetupから古い順まとめてください * 前回のものを見てサマリの書き方は見てください * サマリに必要な情報はSlackやNotionなどを検索してまとめてください 線の正しさは、点が一定量ないとわからない 集めたネタは、ひとつひとつが点です。その点を並べて「これはこういう流れですね」と解釈する、つまり線を引くのは、そんなに難しくありません。これは人だけでなくAIにもできます。情報を渡せば、AIはもっともらしい線をいくらでも引いてくれます。 問題は、その線(解釈)が当たっているかどうかです。そして線の正しさは、点が一定量ないとわかりません。研究の作法を扱ったリサーチのはじめかたという本に、点が少ないとその点を通る線は何本でも引けてしまう、という話があります。資料が少なければ解釈は無限にある。これは引く主体を問いません。人が引いてもAIが引いても、点が少なかったり偏っていたりすれば、それらしいだけの線(解釈)になります。 点がひとつしかない、あるいはほんの少ししかないときに、どうやって点と点をつなぐことができるだろう。まだほんのとっかかりの段階で、解釈や議論──点と点を結ぶ推論の線──をどうして描きはじめることができるだろう。点がひとつ、ふたつ、あるいは三つしかないとしたらどうだろう。 (...中略...) 研究の初期段階では、問いや解釈の可能性が無数にあるから、点と点を結ぼうとしてもあっという間に収拾がつかなくなる。つまりこのパズルは解けないのだ。これほど「点」の数が少ないと、その点を通る線は何本でも引けてしまう。つまり研究者目線で言えば、資料の数が少ないときは、筋立ても解釈も無限に存在することになる。 -- リサーチのはじめかた - トーマス・S・マラニー、クリストファー・レア そのため必要なのは、全員が薄くアンテナを張って、点をたくさん、いろんな方向から集めることです。点が増えるほど引ける線は絞られ、それらしいだけの線が当たる線になっていきます。 たとえば、この数ヶ月のサプライチェーン攻撃がそうでした。axiosやCheckmarx/Bitwardenの侵害（4月）、TanStackのpostmortem、Nx Console拡張の汚染（5月）、CAMPFIREの不正アクセス調査レポート（6月）。どれも単発で見れば「物騒だね」で流れていく点です。 それが数ヶ月、複数人のアンテナで溜まって初めて、「漏れたトークンがCI/CDを踏み台に本番へ権限昇格していく」という一本の線が見えてきました。1点や2点では、ここまでの線は引けませんでした。 場をひらき続けること いちばん大事だと思っているのは、毎週決まって話す場があることです。ただ、この場の目的は、その場で答えを出すことではありません。持ち寄ったネタを声に出し、お互いのアンテナを重ねて、拾えるネタを増やしていき、コミュニケーションに繋がる。それが場の役割です。 たまに「これ先週のあれと繋がるね」と、その場で点と点がつながることもあります。でもそれは狙って起こすものではなく、点が十分たまったときに、ときどき現れるくらいのものです。毎回つなげようと気負わなくていい。点を持ち寄り続けることのほうが、ずっと大事です。 場そのもの（カレンダーの繰り返し予定とMeetのリンク）を用意するのは簡単です。本当に必要なのは、誰かが口火を切り、参加に濃淡があっても回り続けること。スタンプも顔出しもコストは下げてあるので、回す人さえいれば成立します。 線は誰にでも引けます。けれど、その線が正しいかどうかは、集めた点の数と多様さでしか確かめられない。だから私たちは、立派な仕組みを作るより、気になったネタが集まる場として、エンジニアミートアップをやっています。
- 生成AI
- Slack
- セキュリティ
JSAI2026（人工知能学会全国大会）にプラチナスポンサーとして協賛しました
こんにちは！Data＆Analysis部の今野です。 キャディは2026年6月8日(月)〜12日(金)にGメッセ群馬で開催されたJSAI2026（人工知能学会全国大会 第40回）にプラチナスポンサーとして協賛させていただきました。この記事では5日間にわたる開催期間中の当社ブースの出展報告や、聴講した技術セッションのレポートをお伝えします。 会場紹介 ブース紹介 聴講したセッションの感想 非構造データからの情報抽出 画像音声メディア処理：視覚言語理解とマルチモーダル生成 終わりに 会場紹介 まずは会場の様子を紹介します！ 場内では複数のセッション・企業展示・ポスター発表が同時並行で実施されていました。企業展示では、多様な業界に跨る159社の企業が、生成AIに限らない幅広い機械学習技術の産業応用に関して紹介をしていました。私も色々なブースを訪れ、エンジニアの皆さんと意見交換をさせていただきました。 場内の案内図 大規模言語モデル等の生成AIとともにフィジカルAIも大きなテーマの一つとなっていて、実際に入口付近ではGMOインターネット株式会社のブースの前でヒューマノイドロボットが来場者を迎えていました。 入口から見た会場の様子 ブース紹介 次にキャディのブースについて紹介します！ ブースでは、主に私たちが提供している「製造業AIデータプラットフォームCADDi」の中で使用されている機械学習技術や現在取り組んでいる研究開発テーマの紹介をしました。また本サービスのデモを通して、実際に製造業の現場の課題解決にどのように貢献しているかを実感してもらえるようにしました。 注力してR&Dを行っているテーマの中でも、設計資産全体を横断して検索するための2D図面と3D CADモデルの埋め込み空間の統合・3D CADデータ内の加工に必要な特徴の認識・製造業ドメインに特化した独自の視覚言語モデル（VLM）評価ベンチマーク ManuDraw-Benchの3点について紹介させていただきました。 ノベルティとしては、キャディが各所で出展する度に大人気の「データ活用カツ」や製造業をイメージしたマイクロファイバークロスをお配りしました。 図面が文書としての特徴と幾何学的な形状が融合した複雑なデータであることやその中に潜む活用しきれていない情報の価値であったり、テキストや画像と比べるとあまり一般的でない題材の3D CADに対してどのようなアプローチを課題に応じて選択しているかについて関心を持って頂くことができました。 イベント期間中、キャディのブースに立ち寄ってくださった皆さん、本当にありがとうございました！ 聴講したセッションの感想 次に、聴講させていただいたセッションの感想を簡潔にまとめます。 非構造データからの情報抽出 株式会社リクルートの中田さんとSansan株式会社の山内さんがオーガナイザとして実施されたセッションです。 複数ページの請求書 ・医薬品データ・技術マニュアル ・有価証券報告書 など、多種多様な産業の実務に溢れる「非構造データ」から、いかに正確かつ網羅的に情報を抽出するかという共通の課題に対する検証結果が発表されました 。 問題設定及びそれに対して提案された手法は様々ですが、ほとんどの発表においてVLMが手法の中心に据えられていたことが印象的でした。引き続き物体認識やOCRに特化したモデルの有効性は変わらないものの、大規模言語モデルの推論能力を生かした情報の構造化はこの領域において避けては通れないものになっていると感じました。その中で、プロンプトの工夫・画像の前処理・ステップの分割・検索システムの統合など能力を最大限に引き出すための多岐に渡る手法が検証されていました。 図面という非構造化データからの情報抽出は我々の中心にある課題の一つで、日頃の取り組みと密接に関連したセッションであり、これから解析対象のカバレッジを拡張していくに当たり非常に示唆に富んだ内容でした。 https://pub.confit.atlas.jp/ja/event/jsai2026/session/acHLauKQ 画像音声メディア処理：視覚言語理解とマルチモーダル生成 本セッションでは、画像・音声・対話データといったマルチモーダル情報を対象に、人間の認知特性や数理的アプローチを組み合わせて処理のブラックボックスを解き明かし、生成・推論の「制御性と効率性」をいかに向上させるかという共通の課題が議論されました 。 特に印象的だったのは、東京大学の大坂さんによるVLMにおける視覚アクセス境界の存在を実証した研究です 。この研究では、思考のプロセスを言語化させるChain-of-ThoughtプロンプティングをVLMで行う際、モデルが「長く考えること」で視覚的な特徴抽出を拡張しているわけではなく、実際には言語空間内での記号的推論を延長しているに過ぎないという機構を示すものでした。 過去のテックブログでも紹介しているように、図面からより高度な情報の獲得を目指していくに当たり、VLMのメカニズムに起因する視覚情報に基づく推論の限界は我々も課題に感じており、この問題を新たな視点で捉えられる研究内容であるように感じました。 https://pub.confit.atlas.jp/ja/event/jsai2026/session/fQHM84pJ 終わりに 5日間にわたるJSAI2026への協賛・参加を通じて、AIに関するアカデミックな着目点や産業応用における最新の機械学習技術について幅広い知見を得られる貴重な機会となりました。また、会場での多くの交流や専門的なセッションから、VLMの可能性など我々が日々取り組んでいる課題に対してもヒントを得られる非常に有意義な時間でした。 スピーカーの皆さん、参加者の皆さん、運営の皆さん、素晴らしい会をありがとうございました。今後もキャディは技術的な挑戦や現場の課題解決に向けた取り組み、そして研究開発の内容を積極的に発信し、エンジニアコミュニティの発展の一助となれるような貢献を続けていきたいと思っています。 次回、また皆さんとお会いできることを心より楽しみにしています！
- 生成AI
- 機械学習
【2028年問題】Salesforce Open CTI廃止！ 移行負担を減らすAmazon Connect連携パッケージをリリースしました
突然ですが、SalesforceとクラウドPBXを連携させてコールセンター業務を行っているみなさま、「2028年問題」の準備は進んでいますか？ 「……え、2028年問題って何？」 「初耳なんだけど、何かあったっけ？」 そう思った方、安心してください。実はまだ知らない方もたくさんいます。 しかし、知らなかったでは済まされない大きな変化が、今まさに水面下で進行しているのです。 今回は、SalesforceのCTI連携に訪れる激震と、それを賢く乗り越えるためにサーバーワークスがリリースした「新ソリューション」についてお話しします。 実は知らない人も多い「Salesforce Open CTI廃止」の…
- Amazon Connect
- Salesforce
- 生成AI
- AWS
JaSST'26 Tohoku 参加レポート
こんにちは！ QAエンジニアの小竹です。OfficeMobileチームでiOSアプリのQAとして働きつつ、QA外部コネクトチームの一員として他社エンジニアの皆さまとのつながりを生み出す活動に携わっています。 サイボウズは、2026年5月29日（金）に開催されたソフトウェアテストのシンポジウム JaSST'26 Tohoku にスポンサーとして協賛しました。 この記事では、 JaSST'26 Tohoku でのサイボウズの発表についてご紹介するとともに、発表に使用した資料を共有させていただきます。 登壇情報 今回はスポンサーセッションに1名が登壇しました。 新卒1年目QAがリリース基準の"なぜ"をたどってみた speakerdeck.com このLTセッションでは、2025年度新卒入社・山形大学出身の「すずりん（@kir1nak.bsky.social）」から、担当製品のリリース基準の裏に潜む背景・目的を探究し、品質保証プロセスの改善に繋げた話を共有させていただきました。 セッションをご視聴下さった皆様、本当にありがとうございました！ また、SNS上で嬉しいコメントをくださった皆様にも、心からお礼を申し上げます。 登壇の様子 登壇者からのメッセージ 会場でセッションを聞いてくださった皆様、そしてJaSST東北実行委員の皆様、ありがとうございました！ 学生時代を過ごした東北の地で、このような登壇の機会をいただけたことを非常にうれしく思っています。 今回の発表内容が、皆様が取り組む業務改善の一助になれば幸いです！ 終わりに 今回のJaSST'26 Tohokuは、基調講演・事例発表でハーネスエンジニアリングが取り上げられたこともあり、「QAがAIとうまくやっていく」というテーマでの盛り上がりが見られました。 「AIを使って何をするか」を模索する段階から一歩進み、AIという新たな「仲間」をチームに迎え、いかにチームワークを発揮してQA活動を推進していくべきかを考えるフェーズに入ってきたことをひしひしと感じますね。 サイボウズQAはこれからも「チームワークあふれる社会を創る」という企業理念のもと、AIという頼もしいチームメートとともにチームワークをフルに発揮し、kintoneやGaroon、サイボウズ Office、メールワイズなど、チームを支えるサービスをお客様にお届けしてまいります。 QAエンジニア採用強化中！ 現在サイボウズでは、チームの一員として活躍していただけるQAエンジニアを募集しています。 サイボウズの企業理念に共感いただけるQAエンジニアの皆様、私たちと一緒に働きませんか？ 募集要項は以下のページにてご確認いただけます。 cybozu.co.jp カジュアル面談も実施していますので、まずは話だけ聞いてみたい、という方もお気軽にお声がけください！ カジュアル面談のお申し込み たくさんのご応募を楽しみにお待ちしています！
- テスト
- 品質保証
- 生成AI
AI Agent Conference 2026 参加レポート
はじめに こんにちは、SRE部 検索基盤SREブロックの富田です。2026年5月4日〜5日の2日間、New Yorkで開催された「AI Agent Conference 2026」に参加しました。 本記事では、現地の様子と印象に残ったセッションをご紹介します。 目次 はじめに 目次 AI Agent Conferenceとは 特徴 現地の様子 セッションレポート (1) Architecting for the Agentic Customer: Systems Design for Non-Human Actors (2) What Agents Want: Beyond One-Size-Fits-All Retrieval Systems (3) Measuring & Evaluating Agentic AI (4) Workflow Democratization & Operating in an Accelerated Development Environment おわりに AI Agent Conferenceとは AI Agent Conferenceは、エンタープライズ領域における自律型AI（Autonomous AI／Agentic AI）をテーマとする国際カンファレンスです。研究系のAIカンファレンスとは異なり、AIエージェントのエンタープライズ実装に焦点を当て、技術・運用・戦略にわたる深い知見が交わされます。 特徴 本カンファレンスの特徴は、「1つのカンファレンス、3つのAgenticテーマ」というコンセプトでセッションが構成されている点です。2026年は以下の3テーマで議論が展開されました。 Agentic Enterprises：AIエージェントによるビジネスオペレーションの変革 Agentic Engineering：AIエージェントシステムを支えるインフラと設計 Agentic Industries：金融・医療・法務・ロジスティクスなど業界別のユースケース 現地の様子 本カンファレンスは、New Yorkにあるヒルトン・ミッドタウンホテルで開催されました。来場者数は3,000人を超える規模でした。 Agentic Engineeringトラックは来場者数が多く、入場制限のかかるセッションも複数あるほどの人気でした。AIエージェントへの注目度が、想像していた以上に高かったというのが率直な印象です。 会場の様子 会場には70を超える企業ブースが並び、来場者がその場でプロダクトを体験できるブースも多く、終日盛況でした。 ブースのマップ 体験型のブース セッションレポート 検索機能を担当するSREとして、特に印象に残ったセッションを4つ紹介します。 (1) Architecting for the Agentic Customer: Systems Design for Non-Human Actors 本セッションでは、AIエージェントが消費者に代わって買い物をする「Agentic Commerce」に向け、EC事業者やプラットフォームが取るべきアーキテクチャ設計について紹介されました。 GoogleのHeiko Hotz氏によるセッション AIエージェントによる自律的な購買行動を支えるプロトコルは、ここ1年で急速に整備されています。代表例として、A2A（Agent-to-Agent Protocol）、AP2（Agent Payments Protocol）が挙げられます。さらに2026年1月にGoogleがUCP（Universal Commerce Protocol）を発表しました。 発表後の数週間でAmazon・Meta・Microsoft・Shopify・SalesforceがUCPに参画しました。業界全体で、エージェント間通信の標準化が一気に進みつつある状況です。 こうして「外側」の仕組みが急速に整う一方で、LLMベースのエージェント本体には本質的な弱点が残っています。ハルシネーション、予算を超えた購入、悪意のあるサイトに操作される脆弱性です。研究では、エージェントが偽の認証情報や虚偽の主張に騙されるケースが確認されています。セッションでは、これを「人間と同じ感覚で野に放つのは危険」と表現されていました。 セッションで提示されたのは、サンドイッチアーキテクチャと呼ばれる設計パターンです。LLMの強みと、入力が同じなら必ず同じ結果を返す決定論的レイヤー（ルールベースの処理層）を組み合わせ、エージェントの暴走を構造的に抑え込みます。 サンドイッチアーキテクチャの説明スライド 第1層（LLM）：自然言語の意図を構造化属性に変換する。「スコットランドのハイランドをハイキングするための防水ジャケットがほしい」という曖昧な要求を、防水等級・サイズ・想定気温などの具体的な属性に落とし込む 第2層（決定論的レイヤー）：UCPなどのプロトコルに準拠したAPI経由でEC事業者のデータを取得し、属性で確定的にフィルタする。ここでLLMは介入させず、ルールベースで候補を絞り込む 第3層（LLM）：最終決定する。必要なら第1〜2層に戻ってループする このアーキテクチャでは、決定論的なフィルタリングが「LLMが暴走しても結果が破綻しない安全弁」として機能します。 EC事業者側の責務として、AEO (Agentic Engine Optimization) という概念も紹介されました*1。エージェントは画像や装飾ではなく、構造化された属性データしか見ません。商品ページがいくら美しくても、属性データに「急速充電に対応」という項目が抜けていれば、エージェントはその商品を選びません。実験では、ある属性が欠落しているだけで、エージェントは25ドル以上の価格差を付けないと購入対象に含めないという結果も示されました。 最後に、取引の全過程を後から追跡できる記録（監査証跡）の設計が、エージェント時代の信頼性の土台になる、という話で締められました。 AI時代の安全性は、LLMを賢くするだけでなく、その周りに置く決定論的レイヤーをどう機能させるかも重要だと感じました。また、エージェント駆動の購買が広がれば、商品検索の相手は「人間のユーザ」と「AIエージェント」両方になります。商品データの属性を漏れなく構造化し、AEOの観点で「エージェントから評価される」ことも、ECプラットフォームの検索機能の要件として加わってくると思いました。 (2) What Agents Want: Beyond One-Size-Fits-All Retrieval Systems 本セッションでは、エージェントの記憶や作業メモリの役割を果たすコンテキストレイヤーに求められる要件と、それを支えるベクトルデータベース（LanceDB）の設計思想について紹介されました。 LanceDB CEOのChang She氏によるセッション これまでのRAG (Retrieval-Augmented Generation)は、ユーザのクエリ1つに対して数件のテキストを返すだけで成立する世界でした。しかし、エージェントが本番環境で動き出すと、扱うデータとクエリパターンは一変します。 エージェントは計画を立て、並列で検索を投げます。各種ツールを実行して得られた中間結果を随時メモリに記録し、バラバラの情報を要約・集約しつつ、もし行き詰まったら一歩手前のステップに逆戻りして別のルートから調べ直す、といった自律的な試行錯誤を行います。 その結果、コンテキストレイヤーが管理すべきデータはテキストだけでなく、PDF・スクリーンショット・テーブル・動画フレーム・オーディオクリップ・イベントログ・JSONログまで膨らみます。こうしたデータの広がりに合わせて、クエリの種類も多様化します。意味的検索だけでなく、キーワード検索や、特定の顧客IDかつ過去7日間といった構造化フィルタへの対応も必要です。さらにデータの来歴（どの埋め込みモデルを使ったか、いつ書き込まれたか）も管理対象になります。 これらを別々のシステム（ベクトルDB・データレイク・OLAP・メタデータストア）に分散させると問題が生じます。エージェント自身が「どのツールを使うべきか」「返ってきた結果をどう統合するか」の判断にトークンと推論能力を浪費してしまいます。 LanceDBはこの課題に対し、以下のアプローチを取っています。 コンテキスト・来歴・特徴量・埋め込みベクトルの単一テーブル管理：エージェントはSQL、セマンティック検索、フルテキスト検索を同じテーブルに対して投げられる。ツール選択や結果統合の手間が消える データタイプ別ストレージ戦略の抽象化：インラインカラム、ページ単位管理、外部URL参照といったサイズに応じた格納戦略をエージェントから隠蔽する エージェント時代のスケール対応：100億行規模・10K QPSの書き込みは、従来のベクトルDBには想定外の負荷。p99レイテンシを悪化させず安定動作するよう、インデックス・シャーディング・量子化を再設計 バージョニングと再現性：エージェントが探索した分岐の特定時点に戻れる、デバッグ時のリプレイができる仕組み ベンチマーク結果では、エージェントフレームワーク標準のメモリ機能（インメモリの単純な検索）の取得精度が約52％なのに対し、LanceDBに置き換えると約76％まで上がります。取得時間も80秒台から数秒に短縮されると報告されていました。精度を上げると遅くなる、ではなく、正しい構造を選ぶと精度と速度が同時に上がるという結果は、素直に面白いと思いました。 また、AIエージェントが普及していくとデータ量やトラフィック量が大きく変化するため、今後の検索に求められる要件はさらに拡張されていくと感じました。 (3) Measuring & Evaluating Agentic AI 本セッションは、本番環境で動くエージェントの評価とモニタリングをテーマにしたパネルディスカッションでした。 エージェントのトレースは長く、深く、複雑です。1つのインタラクションの中で多段のChain-of-Thought（段階的に推論を重ねる思考過程）が走り、複数のツール呼び出しが連鎖します。そのため、「何が起きたか」を後追いで評価するには専用の仕組みが必要になります。 加えて、LLM-as-a-judge（LLM自身を評価者として使う手法）は、シンプルなユースケースなら安価ですが、エージェントが複雑化すると評価コストが急騰します。判定にも高価なモデルを使うため、本番規模ですべての出力をjudgeで評価する運用はコスト面で困難です。 さらに、オフライン評価（事前に用意した正解集に対する評価）と本番モニタリング（実行時の観測）が分断されており、両者をどう接続するかが課題になります。組織によって重視する軸もコスト・速度・リスクと異なるため、画一的な指標も置きにくい状況です。 パネリストからは、以下のような実践的なアプローチが共有されました。 指標はユースケース起点で設計する：「営業支援エージェントなら何を測るか」をユースケース単位でアカウンタビリティ・フレームワークとして定義する 「Cost per Successful Outcome」を中心指標に：単なる精度やレイテンシではなく、成功した結果1件あたりのコストで全体を見る LLM-as-a-judgeのコスト最適化：評価ごとに高価なLLMを呼ぶとコストが膨れ上がるため、本番規模ではSLM（小規模言語モデル）などの軽量モデルに切り替え、品質を保ちながらスケールさせる オフライン評価と本番モニタリングの継続的フィードバックループ：本番の挙動をオフライン評価に取り込み、評価セットを継続的に更新する 既存の観測スタックに乗せる：OpenTelemetryなど既存の観測基盤にエージェントの計装を統合し、モデル選択（LLMとSLMの使い分け）まで1つのダッシュボードで管理する また、Microsoftのagent-governance-toolkitも紹介されていました。ポリシー強制・サンドボックス・OWASP Agentic Top 10対応など、エージェント運用全体を標準化しようとするツールキットです。 個人的に印象に残ったのは「Cost per Successful Outcome」という指標の話でした。精度やレイテンシを個別に追うのではなく、成功した結果1件あたりのコストで全体を見るという発想です。この観点で見ると、高価なLLMを使い続けるよりも、品質を保ちつつ徐々に安価なモデルに切り替えていくのが自然な方向だと感じました。実際、パネルディスカッション内でも同様のアプローチが議論されていました。 「エージェントが本番で失敗したとき、誰が責任を取るのか（エンジニア・プロダクトオーナー・エージェント自身）」という問いも面白かったです。「もはやみんなが互いの役割を担うようになっているので、全体を1つのシステムとして見るしかない」というのもAI時代の形だと思いました。 (4) Workflow Democratization & Operating in an Accelerated Development Environment 本セッションでは、NVIDIA Applied AI Labが10週間で25個のCLIツールを4人で構築した実例を交えて、AIエージェントのみで完結する開発パイプラインの設計思想が紹介されました。 NVIDIA Applied AI LabのJulie Yaunches氏によるセッション 冒頭で「AIが生成できるコード量と、コードレビュー・CI・自動テストといった既存の開発プロセスが吸収できる量の間に大きなギャップが生まれている」と問題提起がありました。このギャップを放置すれば、品質劣化・技術的負債の蓄積・アーキテクチャドリフトが避けられません。セッションでは、10月以降は一行も自分でコードを書いていない、それでも品質を担保する仕組みが必要だった、というエピソードも紹介されました。 NVIDIA Applied AI Labが採用しているのは、Research・Gates・Sweepsという3つの実践です。 Research：何かを作り始める前に、開発対象のコードベースを理解するた
- 生成AI
- RAG
- データベース
「プロダクトで成果を出す」 ──Contract Oneのプロダクトマネジャーが職種の枠を越えて挑戦する理由
「プロダクトで成果を出す。そのために必要なら職種の枠にはこだわらない」 そう語るのは、取引管理サービス「Contract One」のプロダクトマネジャー（PdM）を務める午菴と北野です。二人がいま向き合っているのは、AIによって大きく変わり始めたプロダクト開発の現場です。PdM自らがUI改善を実装し、エンジニアは事業視点で提案し、法務メンバーも企画や商談に入り込む。役割や肩書きにとらわれず、それぞれがプロダクトの成果に向けて動いています。役割や職種の枠を越えて挑戦する。そんなContract One事業部では、どのようなプロダクトづくりが行われているのでしょうか。 異なるキャリアを歩んできた二人に、Contract Oneならではのプロダクトづくりと、そこでPdMが果たす役割について聞きました。 午菴 夏希 / Natsuki GoanContract One事業部 プロダクト室新卒で広告代理店にて営業・販売促進・新規事業に従事。2017年よりデザイナーに転身し、大手人材企業の転職サービスの企画・開発を担当。 2020年12月にSansan株式会社へ入社し、ビジネスデータベース「Sansan」のプロダクトデザイナーを経て、2024年からContract Oneのプロダクトマネジャー兼プロダクトデザイナーを務める。 北野 浩司 / Koji KitanoContract One事業部 プロダクト室大学院卒業後、外資系計測機器メーカーにエンジニアとして入社し、研究開発者向けSW/HWのテクニカルサポートに従事。その後、製造業調達部門に特化したSaaSスタートアップに転職。マーケティングや導入活用支援を兼務したのちプロダクトマネジャーとして新規事業の立ち上げに携わった。 2025年8月にSansan株式会社に入社し、プロダクトマネジャーとしてContract Oneの製品企画を推進している。 「事業のためなら何でもやる」──異なるキャリアからContract OneのPdMへ ──これまでのキャリアについて教えてください。 午菴：はじめは広告代理店で営業をしていたのですが、お客様と深く向き合う中で「作って届けるところまで関わりたい」という気持ちが強くなり、デザイナーに転身しました。 そこでさまざまなクライアントの案件に携わるうちに、今度は一つのプロダクトに長期的に向き合いたいという思いが生まれ、事業会社への転職を考えていたタイミングでSansanを知りました。個人的にも名刺アプリ「Eight」を使っていて、そこで出会った人との縁が仕事につながった経験もあったので、以前からSansanのミッションには共感していました。Sansanへ入社後はデザイナーとしていくつかのプロダクトに携わり、約2年前からContract OneのPdMを務めています。異動のきっかけは、事業責任者の尾花から「PdMをやってみないか」と声をかけてもらったことでした。 ──PdMをやってみることに抵抗はなかったのですか。 午菴：全くありませんでした。私の働くモチベーションは、事業への貢献を実感できることにあります。ユーザーに良い体験を届けたり、身近なチームメンバーの助けになったり、形はさまざまですが、自分の働きが誰かの役に立っている瞬間が好きなんです。なので、「デザインじゃないといけない」というこだわりは特になかったですね。ちょうどPdMが足りていなかったこともあり、「事業のためなら何でもやります」という気持ちで引き受けました。今振り返ると、尾花が評価してくれていたのも、デザイナーとしての専門性以上に、そのスタンスだったのだと思います。 ──北野さんのこれまでのキャリアについても教えてください。 北野：大学院でシステム工学を専攻したのち、新卒入社した外資系の計測機器メーカーではエンジニアとして技術サポートや研修講師の仕事をしていました。 当時、仕事に一定のやりがいは感じていましたが、「新しい事業やプロダクトを作る挑戦がしたい」という思いが次第に強くなり、ご縁のあった創業期のSaaSスタートアップに転職しました。 そのスタートアップでは最初カスタマーサクセスの立ち上げに関わり、その後マーケティングも兼務するようになりました。そうした折に社内で新規プロダクトを立ち上げる話が持ち上がり、「お客様のことをよく知っているし、技術系のバックグラウンドもあるから」と声をかけてもらってPdMに転身しました。そこからはプロダクト開発の仕事を続けています。 ──Sansanに入社したのはどういった経緯ですか？ 北野： 私は、複雑な業務を解きほぐして、そこから得られたマニアックなインサイトをもとに課題を解決する、というプロセスがすごく好きで（笑）前職でも自動車業界特有の複雑な商習慣や帳票構造を読み解いて、得られた知見をお客様への活用提案やコンテンツ作成につなげることや、汎用的な機能としてプロダクトに落とし込むようなことをやっていたんです。そうした経験やスキルが生かせる次のチャレンジを探していたときにContract Oneに出会い、「契約書」という領域が面白いと思いました。 会社ごと、業界ごとに扱う契約書は大きく異なります。そこには各社・各業界固有の商慣習や取引の知恵が埋もれていて、まだ体系的な知見として整理されていない領域がたくさんありそうだと感じました。もう一つは、Sansanという会社自体への興味もありました。 以前からSansan社員の外部発信を見ていたので、PdMとして成長できる環境があるという印象を持っていましたし、Bill Oneの目覚ましい成長を見ていたので、Sansanが持つ組織的な営業の強さは確信していました。一定の顧客基盤と営業組織が整った会社の中で、これから伸ばそうとしている新規事業領域で働けば、自分が作ったものが社会により大きなインパクトで届くはずだという期待もありました。 AIで開発スピードは3倍に。Contract Oneで起きている変化 ──現在携わっているContract Oneとは、どのようなプロダクトなのでしょうか？ 午菴：Contract Oneは、契約書・発注書・見積書など、ビジネスで発生するあらゆる取引書類をデータ化・構造化して管理・活用できる取引管理サービスです。紙・電子を問わず高精度でデータ化し、契約書になじみがない方でも取引の条件や変遷を一目で把握してビジネスに生かせる環境を提供しています。 直近ではMCPサーバーの提供を開始するなど、契約データベースと生成AIを接続した新たな価値提供にも積極的に取り組んでいます。 jp.corp-sansan.com ──Contract Oneの企画が生まれるプロセスを教えてください。 午菴：いくつかパターンがありますが、まずは「ユーザーフィードバック」ですね。Sansanには、プロダクトごとにユーザーからのフィードバックを集約したSlackチャンネルがあり、お客様と接するフロントメンバーが、ヒアリングした要望や課題をSlackチャンネルに投稿してくれる仕組みがあります。 私たちPdMも常に目を通しているので、すぐに対応できそうなものは即座に企画として動かしています。次に、新規顧客の提案ベースで生まれるもの。「この機能がないから導入に踏み切れない」という場面で、クイックに意思決定して実装するというケースが結構あります。そして、将来的なプロダクトの方向性から逆算して「これをやるべきだ」という私たち自身の意志として考えるもの。あとは、ビジネス側からだけでなく、エンジニアから提案が上がることもよくあります。具体的には、パフォーマンス改善や将来の発展性を見据えた技術的な提案もありますし、ユーザーフィードバックを見て、「これすぐ対応できますよ」と自主的に拾い、課題や要件を整理してくれることもあります。そうした声を受けて、優先度を柔軟に組み替えることも多いですね。 ──AI活用によってプロセスはどう変わりましたか？ 午菴：企画プロセスの大きな流れは変わっていませんが、各ステップのスピードと精度が上がりました。 チームではClaude Codeを活用していて、議事録や社内ドキュメント、Slack、Salesforceなどあらゆる情報を参照しながら企画検討を進められるようになりました。提案資料やプロトタイプをクイックに作ってお客様に提案し、フィードバックをもとに修正してまた見せる——このサイクルが劇的に速くなっています。プロトタイプを作りながら企画を詰めていくので、企画が固まる頃にはある程度の体験も出来上がっている。結果として、新機能を届けるまでのスピードも上がってきていると感じます。実際の開発スピードも体感で2〜3倍くらいになっています。 以前は限られたリソースの中で「どれを優先するか」を必死に議論していましたが、今はAIによって開発スピードが劇的に上がり、「何を諦めるか」ではなく「いかに早く次の企画を生み出すか」という前向きな議論に変わりました。 ──以前別のインタビューで「簡単なUI改善ならPdMが自ら実装してリリースしている」と伺ったのですが、本当ですか？ 北野： はい、こちらの記事でも触れていますが、エンジニアだけでなく、PdMやデザイナーも影響範囲の限られた改善であれば自ら実装・リリースできるようにしています。AIを活用しながら、必要なチェックを経ればリリースできるルールを設けています。 PdMやデザイナーが自ら実装・リリースできるようになったことで、それまで開発リソースの都合で優先度を上げきれずにいたユーザビリティの課題をどんどん解消できるようになりました。そうした改善が進んだ結果、以前と比べてお客様からいただくフィードバックの純度が上がってきた感覚があります。表面的な問題が解消され、より本質的な課題にフォーカスが当たるようになってきた。 そうすると「事業を伸ばすために次に何をやるべきか」についての認識が、チーム内で自然と揃ってくるんです。これはAIを活用する前では得られなかった感覚で、興味深い発見でしたね。 エンジニアも法務も。“職種を越えて”プロダクトを作る ──エンジニア組織との距離感はいかがですか？ 午菴：エンジニアとの距離はかなり近いです。毎日のように誰かが私たちの席の隣に来て、気軽に話せる環境ですね。企画の早い段階からアーキテクトやエンジニアに入ってもらい、事業の状況や数字を共有しながら方針について議論しています。 だからこそ、技術負債の解消や将来の発展性を見据えた提案はもちろん、ユーザーフィードバックを拾って課題や要件を整理してくれることもあります。あとは、ミーティングの録画や議事録は全員がいつでも参照できる状態になっているので、自然と状況を把握して提案や相談をしてくれたり、ときには「これってどんな状況ですか？」という一言をきっかけに案件が動き出すこともあります。北野：入社して感じたのは、エンジニアがとにかく優秀だということです。技術だけに閉じず、事業がどうすれば伸びるかに強い関心を持っている。内部品質と事業インパクトのトレードオフが生じる場面でも、高いレベルでバランスよく判断している印象があります。新卒メンバーでもそういう視点で話をしているので、最初は驚きました。 ──職種を越えた連携という点では、法務担当との協業もユニークだと伺いました。 午菴：はい。法務担当のメンバーがドメインエキスパートとしてPdMのように企画から入り、さらに自らお客様の商談に同席して、熱量を持って提案することもあります。 AI時代に法務の業務がどう変わっていくべきかを自ら検証し、最前線で動いているんです。こうした職種の垣根を越えた連携は、Contract Oneの大きな強みですね。 「プロダクトで成果を出す」がPdMのミッション ──Contract OneにおけるPdMの役割はどう定義されていますか？ 午菴：以前、チームで「ミッションを言語化しよう」と話したときに、「プロダクトで成果を出す」という言葉になったんです。つまり、プロダクトで成果が出ることなら何でもやる、ということだと思っています。 企画をして、デリバリーのプロジェクトマネジメントをするのはもちろんですが、商談への同席も、展示会への参加も、社内で困っていることへの壁打ちも、デザインもやる。それぞれの得意なことを生かしながら、必要なことを必要なときにやっていくイメージです。北野： 実際、商談に同席する機会は多いですね。企画の方向性を考えるときにお客様の反応を直接見たいという目的で参加することもありますし、営業のメンバーから「提案に同席してほしい」と声がかかることもあります。 PdMの役割がきっちり定義されていないからこそ、そういう関係性が自然に生まれているのだと思います。私自身、お客様との接点が多い方が仕事しやすいタイプなので、こういう環境はとてもありがたいなと感じます。 ──AIが普及した時代に、PdMが担うべき価値とは何だと思いますか？ 午菴：AIの普及により判断材料が増え、スピードも上がりますが、どこに向かうかの意思決定は人の役割ではないでしょうか。 また、AIを活用することで生まれた時間を使って、一次情報をより取りにいけるようにもなりましたね。商談への同席もそのひとつで、そこでしか得られない
- プロダクトマネジメント
- 生成AI
- UIUX
Web未経験MLエンジニアが社内プロダクト開発でAIコーディングにどハマりするまで
Web未経験MLエンジニアが社内プロダクト開発でAIコーディングにどハマりするまで はじめに こんに ...
- 生成AI
- フロントエンド
- React
- TypeScript
- Terraform
OpenAIエンジニアによるCodexを「自律エージェント」として使い倒すための勉強会レポート
こんにちは、DeNA ヘルスケア事業本部ウェルビーイング事業部DXソリューション部の川上知宏です。 現在弊社では「AI オールイン」を掲げ、プロダクト開発のあり方そのもののアップデートに取り組んでいます。 今回はその一環として、OpenAI 社から 3 名の講師をお招きし、OpenAI が提供する、複雑なタスクを自律的に実行し、人と協働しながら仕事を前に進める AI エージェント「Codex」に関する勉強会を開催しました。 オンラインで開催された 1 時間のセッションには、300 名を超える社員が集まり、大規模な勉強会となりました。
- 生成AI
- LLM
AIへの指示ファイル設定どうしてる？私の場合のお話
はじめに 今月お誕生日の人、おめでとうございます🎉エデュケーショナルサービス課の森純子です。 最近は、業務でも日常生活でも生成AIを使うのがすっかり当たり前になってきましたよね。 さまざまなAIツールがある中で、今回は私が愛用しているAIコードエディタ「AWS Kiro（以下、Kiro）」の「Agent Steering（以下、ステアリング）」という機能についてのお話です。 これは簡単に言うと、「新しくチャットを開くたびに、毎回同じ指示を打ち込む面倒くささをゼロにする機能」です。 たとえば、新しくチャットを開くたびに「丁寧語で書いて」「マークダウンは使わないで」と何度も同じ指示を入力するのは大…
- 生成AI
- プロンプトエンジニアリング
- AWS
おばあちゃんと家族のためのテレビ電話を自作した話
はじめに さくらのナレッジ編集部の法林です。 ある日、さくナレ編集部に読者からのお便りが届きました。そこには、「高齢者の家族が子どもや孫たちとビデオで会話する仕組みを、さくらインターネットのサーバを使って作りました。せっ […]
- JavaScript
- さくらのVPS
- ビデオ会議
- 生成AI
Sansan Data Intelligenceが目指すデータの未来：プロダクト・エンジニアリング・ビジネスの三位一体で挑む新規事業
複数のシステムに散在するデータ、表記揺れや重複、更新漏れ。CRMとSFAで異なる情報が登録され、どれが正しいのか分からない。 こうした「データの信頼性」という構造的課題を解決するために生まれたのが、データクオリティマネジメント「Sansan Data Intelligence」です。Sansan Data Intelligenceは、Sansanが培ってきた名寄せ技術とSansan Organization Code（SOC）を活用し、企業が保有する取引先マスターのクオリティー向上を一気通貫で実現するプロダクトです。 2025年12月にリリースされ、現在はさらなるプロダクトの進化に向けた開発が進んでいます。今回は、Sansan Data Intelligenceに携わる3名——プロダクト戦略を統括する猿田、エンジニアリング組織を率いる多賀谷、そしてビジネスサイドからプロダクトマーケティングを担う鳴海に、Sansan Data Intelligenceの現在地と、この事業を一緒につくる仲間に求めるものを聞きました。 猿田 貴之（Sansan事業部 SDIプロダクト室 室長）Sansan Data Intelligenceプロダクト全体の方向性を統括し、プロダクトマネジャー・データサイエンティスト・デザイナーのマネジメントを担当。Sansan Data Intelligenceの立ち上げ前から一貫して携わり、2025年12月のリリースを経て、さらなるプロダクトの進化をリードしている。 多賀谷 洋一（技術本部 Data Intelligence Engineering Unit 部長）2025年12月のSansan Data Intelligenceリリースタイミングで入社。エンジニアがプロダクトマーケットフィットに集中できる体制構築や、より大きな役割を定義して任せる環境づくりを推進している。 鳴海 佑紀（Sansan事業部 Sansan DI推進部 副部長）Sansan Data Intelligence推進部にて営業・マーケティング・カスタマーサポートを統括。プロダクトマーケティングマネージャー（PMM）として、プロダクトをマーケットに届けるための全体設計と戦略策定を行う。Sansan Data Intelligenceの必要性を1年近く提唱し続け、立ち上げに至った経緯を持つ。 Sansan Data Intelligenceとは何か ──まず、Sansan Data Intelligenceを一言で説明するとどういったプロダクトですか？ 猿田：一言で言うと、お客様が持っている取引先マスターのクオリティマネジメントを実現するプロダクトです。もともとSansanには「Sansan Data Hub」という機能があります。これは名刺を起点に、集まったデータをCRMやSFAに流し込んで営業活動に使うというもので、主なユーザーは営業担当者です。一方でSansan Data Intelligenceが見ているお客様は、その手前で困っている人たち──情シス部門やDX部門、営業企画といった、全社のデータガバナンスを担う方々です。お客様の社内では、複数のシステムに同じ会社のデータがバラバラに登録されていて、表記揺れや重複、更新漏れが起きています。そのカオスな状態を、Sansanが持つ名寄せ技術とSOC（Sansan Organization Code／企業や事業所に対して付与される一意のコード）で整理し、クレンジングした上で足りない属性情報を補完する。 これを一気通貫で提供するのがSansan Data Intelligenceです。Sansan Data Hubが「名刺起点で営業をさらに強くする」プロダクトだとすれば、Sansan Data Intelligenceは「取引先マスター全体の営業DXの土台を作り、作り続ける」プロダクトになりますね。 顧客が抱えるデータ課題のリアル ──ビジネスの現場では、顧客のデータ課題はどのような形で見えていますか？ 鳴海： 特に多いのは、情報システム部門と営業企画・事業部門の方々からの相談です。前者は「データをクリーンに保ち続けたい」、後者は「データを使って事業戦略を考えたい」という欲求を持っていて、共通しているのは「社内のシステムにあるデータが全然信じられない」ということです。例えばCRMには昔の営業担当が登録した取引先情報が入っていて、SFAを見ると別の表記で書いてある。当社で言えば、創業時は漢字の「三三」で、今はアルファベットの「Sansan」ですよね。当時取引した会社のシステムには漢字の「三三」が残っているはず。その情報は間違ってはいないけれど、今は古い。こういうことが事業部門ごとのシステムで起きていて、もう何が正しいか分からない状態になっています。あるお客様は保有データが270万件あり、毎月5,000件ずつ増えていきます。こうなると、ショットで綺麗にすること自体がもう絶対に不可能ですし、次の日からデータは汚れていく。だからこそ、データそのものを継続的に維持する仕組みが必要なんです。さらに外部環境としてAI活用が求められる中で、「来月にはデータが綺麗になります」とか「ショットクレンジング頑張ります」では間に合わない。待ったなしのスピード感で、構造的に解決し続けるプロダクトが必要とされています。 Sansan Data Intelligenceのロードマップとビジョン ──プロダクトとして、半年から1年後にどういう世界を実現したいのでしょうか。 猿田： 短期的には鳴海が言った通りで、お客様の社内に散らばっているデータがちゃんと使える状態になり続けていることを「当たり前」にしたい。具体的には、SOCとその裏側にあるデータが今、570万法人・1,000万事業所をカバーできる規模に拡大しています。これをさらに増やしていくことで、「うちのデータでは識別できない」と言われていたお客様にも応えられるようになってきています。1年後の話をするともう一段やりたいことがあって、それは「AIが使えるデータの供給レイヤー」として位置づけられることです。皆さんがAI活用でいちばんつまずくのは、AIモデルの性能そのものではなく、AIに食わせるデータが揃っていないということだと思います。社内のデータがバラバラだったり、表記揺れしていたり、重複している状態では、どんな優秀なAIがあっても精度の高い回答は返ってこない。Sansan Data Intelligenceはそこを構造的に解決し続けるプロダクトでありたい。クレンジングされて、識別コードが振られて、会社情報や事業所情報がひも付いている—いわゆるAI-Readyなデータを、APIやMCPのような形で各社のシステムやAI環境に供給していく。「まずはSansan Data Intelligenceを通してデータ活用しよう」と思ってもらえる存在を目指しています。まさにSansanが掲げる「ビジネスインフラになる」というビジョンを実現する、インフラ側のプロダクトです。 エンジニアのマインドセットと技術的挑戦 ──プロダクトを支えるエンジニアチームは、どういうマインドセットで向き合っているのでしょうか。 多賀谷：大前提として、これは新規プロダクトであり、プロダクトマーケットフィット （PMF） させることが最優先です。だからエンジニアも、お客様や営業組織、カスタマーサクセス、プロダクトマネジメントといった他部門に積極的に染み出していって、一緒にPMFさせるという姿勢が重要です。技術的には、プロダクトのコアバリューを作る領域をしっかり見極めて丁寧に設計・実装しつつ、逆に既存システムがある部分は早く作れるアーキテクチャで進めようといった意思決定をしていく。そのバランス感覚がエンジニアのマインドセットとして大事なところですね。 ──ビジネス要件が技術そのものを変えた場面はありましたか？ 多賀谷： いちばん重要なのは「SOC v2」と呼んでいるデータアーキテクチャです。EntityとRelationshipという非常にシンプルな構造で、過去の履歴も含めた企業や事業所のデータ構造を表現できる。シンプルでありながら柔軟性が高い設計になっていて、ここがビジネスの競争優位性になっています。そのデザインを提案したドキュメントを見るだけでワクワクするような、そういうものですね。既存のSansan Data Hubのシステムもありながら、新しく作るところは完全に新しく、モダンなアーキテクチャになっていて、それが併存している。このビジネス要件と既存要件が技術判断に与えた影響は大きいです。 プロダクト・エンジニアリング・ビジネスの連携 ──エンジニアリングとプロダクト開発の連携は、具体的にどのように成り立っているのでしょうか。 猿田：Sansan Data Intelligenceでは、プロダクトマネジャーが所属するプロダクト側と、多賀谷率いるエンジニアチームで開発体制を組んでいます。大きな価値提供の単位としてEpicを定義し、その中にユーザーストーリーがあり、さらにその下にPBI（プロダクトバックログアイテム）がある。これを、基本的にエンジニアとPdMが一緒に作っていく運用です。単に「PdMが要件を書いて投げて、あとはエンジニアが実装する」という分業ではなく、Epicという大きな価値のレベルから一緒にリファインメントしていくのが特徴です。SOC v2のような技術的な設計議論にもPdMが入っていって、プロダクトの競争優位に関わる議論を一緒にしています。同時に、短期的な事業要求もすごく高いので、その両立をどう図るかは鳴海、多賀谷と一緒に常に議論しているところですね。SOC v2やSansan Data Intelligenceのアーキテクチャという大きなピクチャーを描きながらも、既存のSansan Data Hubのお客様をも新しい世界にお連れしたい。事業の計画とエンジニアリングの計画を綿密にすり合わせる必要があるので、そこはかなり難しいですが、やりがいのある部分です。多賀谷：別の観点で補足すると、エンジニアに対しては「シフトレフト」の考え方を推進しています。もともとはQAやセキュリティーの文脈で使われる言葉ですが、自分よりも前工程の方にどんどん染み出していこうと。さらに、Sansanが評価の仕組みとして採用している「ミッショングレード制度」では、グレードが上がるほど影響範囲を広げることが期待されています。 グループレベル、部署レベル、あるいは事業目線──次のグレードを目指して、より大きな範囲の仕事を任せ、その期待レベルで仕事をしていくように意識づけをしています。それによってエンジニア、プロダクト、営業組織が三位一体となって仕事できるマインドセットや環境を醸成しています。 部門間連携がもたらす効果 ──ビジネスサイドから見て、この連携体制にはどのようなメリットがありますか？ 鳴海：お客様に対する説明の解像度がぐっと高まるというのは、営業もCSもみんな感じていると思います。データ系のプロダクトなので、お客様からの質問が深いんですよ。「なぜこのデータを識別できないのか」「識別要件は何か」「データの更新頻度はどうか」──こういう技術的な質問を毎回持ち帰ってしまうと商談は長引くし、お客様の熱も冷めてしまう。でも当社のエンジニアの特徴として、現場から「なぜこの人はそういう質問をしたんだろう」と背景を聞いてくれる方が多い。コンテキストを間違えずにやりとりができるので、営業もその解像度で話せるようになります。 実際、社内でもトップ営業の人間はSansan Data Intelligenceやデータマネジメントに関して「すごく詳しいね」とお客様からコメントをもらえたりする。それはやはり、部門を超えて近い距離で協働しているからこそだと思います。あとは、部門を超えたマネジャー会議を毎週やっていたり、四半期に1回「ざっくばらんの会」と称して、エンジニアからビジネスサイドまで全員集まってピザを食べながら話す場を設けていたり。そういうマインド醸成も含めて、みんな前のめりで参加してくれるのはありがたいですね。 Sansan Data Intelligenceにどんな人が来てほしいか ──Sansan Data Intelligenceにどんな人に来てほしいか、それぞれの視点から聞かせてください。 多賀谷： まずは、新規事業を一緒に作るというマインドを持ったエンジニアです。ただ、新しいものを作るだけでいいかというと、そうではない。裏側はデータプロダクトなので、技術的に難しい領域でもあります。その高い技術水準にもチャレンジしつつ、新規事業としてビジネスも成立させる──その両立を目指せるエンジニアと一緒に働きたいですね。鳴海：お客様の業務やペイン──つまり痛みそのものに興味を持ってくれるかどうかが大事だと思っています。自分が企画するもの、自分が作るものが、お客様の現場の何を変えるのかを自分の言葉で語ってくれる人がいると、こちらも相談しやすいし、もっと情報を取ってこようという気持ちになります。もう一つ、新規事業なので「言われたから作ります」という受け身の姿勢だとスピード感が追いつかない。「これが必要だよね。これができたなら、次はこれも必要だよね」と、連鎖的に思考を巡らせてくれる方が入ってくれると、間違いなくフィットすると思います。猿田：補足するなら、「How」に
- 生成AI
- データ分析
- 組織運営
AIエージェント時代の権限管理が、いまアツい
こんにちは。LayerXで「Ai Workforce」というプロダクトのプロダクトマネージャーをしているinaoです。 Ai Workforceは、組織の中でAI Agentを活用するためのプラットフォームです。 getaiworkforce.com おかげさまで、我々の組織もお客様もユースケースも拡大を続けていて、AI Agentとその周辺機能を日々企画・開発しています。そのなかで、最近とくに議論が長引くテーマがあります。 権限管理です。 社内Slackで権限の話を始めると、毎回スレッドが伸びます。私もさまざまな方と意見交換するたびに新しい視点が得られ、とても面白い領域だと感じています。（そういう意味で、社内的にいまアツい、です） 視点が増え、論点が分岐し、さらにスレッドが伸びる。なぜこんなに難しいのか。そして、なぜ「いま」これを考える意味があるのか。この記事では、権限管理を 過去（これまでの前提）／現在（各社の動向と現場の論点）／未来（向かう先） の時間軸で整理してみたいと思います。 最初にお断りしておくと、Ai Workforceは「さまざまな業務を支援・遂行するためのAI Agentプラットフォーム」という位置づけです。そのため本稿も、特定の理想形に絞らず、「さまざま」を扱うための権限管理について、雑多に考えを広げています。その前提で読んでいただけると幸いです。 なぜ権限管理がエージェントの肝になるのか 個人のAIと組織のAI 組織の中にAIを配置し、安全かつ効率的に運用する。人とAIがコラボレーションする。そう考えたとき、設計の肝になるのは「どの権限を、誰に、どこまで、どうやって渡すか」です。 ここが決まらないと、エージェントは安心して仕事を任せられる同僚にはなれません。逆に縛りすぎれば、できることが少なく、柔軟性の低いものになってしまいます。 面白いのは、議論すると人によって意見が様々であることです。理由はおそらく2つあります。 想定しているユースケースは人によって違う。 個人の生産性ツールとしてAIを使う文脈と、組織の共通リソースとして業務を自動化する文脈とでは、最適な権限のかたちはまるで変わります。 個人利用のClaudeやChatGPTに求められることと、組織の中のAgentに求められることも違ってきます。 権限への立ち位置が違う。 業務を設計する人と、業務で扱うリソースを設計する人とでは、「⚪︎⚪︎権限」に対するスタンスが異なります。 しかも、いまだ世の中に存在しないもので、人間にはとてもわかりづらい権限について想像しながら話しているため、人によって思い描く理想像もずれていきます。この課題を完全に解消できるかは怪しいですが、整理することで、議論の足場くらいは作れるはずです。 過去：主に人間を中心に設計されてきた権限管理 これまでのソフトウェアの権限管理は、システム間の連携のようなアクセス制御やルールもありますが、概ね一貫して「人間」を中心に設計されてきました。代表的なものを並べてみます。 RBAC（Role-Based Access Control）：アクセスの主体は人間のユーザーで、権限をロールやグループに束ねる。 ABAC（Attribute-Based Access Control）：主体（ユーザー／システム）に加えて、対象リソースの属性とポリシーでアクセス可否を決める。 ACL（アクセスコントロールリスト）：「誰が見られる／編集できる」をフォルダ・ファイル単位で管理する（Google Drive、SharePoint、Boxなど）。 認可（OAuthなど）：アプリがユーザーの代わりに何かするとき、フローを通じて「ユーザーの許可」をもらいアクセストークンを取得する。リソース側からは、ユーザー本人の行動かアプリの行動かをほぼ区別できない。 これらの世界には、共通する暗黙の前提がありました。 行為者は人間か、または人間の意図を忠実に転送するだけのプログラムである。 ボタンを押したのは人であり、アプリはその意図を運んでいるに過ぎない。だから「誰がやったか」は実質的にユーザー本人と等しく、監査ログにユーザー情報が紐づけば十分。 つまり、意図の出どころは常に人間という点です。 現在：エージェントは「自律的な行為者」になった エージェントによって、何が変わったのでしょうか。 一言でいえば、意図を「転送」するのではなく、文脈から意図やアクションを「生成」するようになったことだと考えています。 人間が「この資料をまとめて」と頼むと、エージェントはどの情報を参照し、どう判断し、どんな成果物を作り、どのアクションを実行するかを、自分で決めていきます。たった一回のクリックの後ろで、数十の判断とアクションが連鎖する。ここで、従来の前提が静かに崩れ始めます。 課題1：主体をユーザーのままにすると、「誰がやったか」区別がつかない リソース側（内部データや外部システム）は、「ユーザー本人が操作したのか」「エージェントが自律的に動いたのか」を見分けられません。監査ログ上は同じに見えるため、事故が起きたときに「誰が」やったのかを後から辿れなくなります。 また、ユーザーの権限を継承してエージェントが情報にアクセスしてしまうと、情報セキュリティ上に外部に送ってはいけない情報が外部システムとしてのエージェントに渡されてしまったり、エージェントを通してさらに外に送信されてしまうおそれがあります。 課題2：エージェント固有の権限で動かすと、「できること」がブラックボックス化する エージェントにサービスアカウントを与えてその権限で動かすと、ユーザーの権限とエージェントの権限が乖離します。それで良い場面もありますが、ユーザー本人には許されないことを、エージェント経由で実行できてしまう、ということも起こりえます。 エージェントからアクセスできる範囲やできることがユーザーから見て分かりづらくなってしまったり、ガバナンスが適切に効かせられているかどうか分かりづらくなってしまうかもしれません。 課題3：人への依頼と、エージェントへの依頼は「責任の所在」が違う 「AさんがBさんに作業を依頼する」のと、「AさんがエージェントA′に依頼する」のは違います。Bさんには本人の判断と責任がありますが、エージェントA′が何をどこまでできるのかを、Aさんが正確に把握しているとは限りません。把握できていないことが、トラブルや業務の停滞につながりかねません。 各社のプロダクトはどう設計しているか エンタープライズ向けにAIエージェントを提供する各社も、同じ課題に向き合っているはずです。公開情報をもとにざっくり調べたところ（※すぐ触れる環境がなかったため厳密さは欠きます）、大きく2つに分かれそうでした。 実行ユーザーの権限を継承するタイプ 例：SalesforceのAgentforceのEmployee Agent。 エージェント自体に独立した権限モデルを持たず、実行ユーザーの権限をベースに動く。基本的にはユーザーに許可を求める仕組み。 エージェントを第一級のアイデンティティとして扱うタイプ 例：Google Cloudの「Agent Identity」、Microsoftの「Entra Agent ID」「Agent 365」。 エージェントそのものに身元と権限を持たせる。 どちらが良いではなく、それぞれの体験、汎用性を踏まえて設計されているように見えます。 また、各社のプロダクト以外にも、OAuthやMCPを中心に標準化の動向や議論もあるようです。（ここは話が広がりすぎるので、また別の機会に） いま現場で起きている論点 世の中の動きと同じことが、社内でも論点として立ち上がってきます。 （以下はあくまで社内で出ている論点の一例で、権限管理の一般的な論点を網羅したものではないのでご注意ください） 1. 代行か、依頼か 1つ目は、エージェントが「誰の権限で」「どこまで自分で判断して」動くかという軸です。業務の任せ方には2種類あります。 業務の代行：自分の仕事をそのまま肩代わりしてもらう。エージェントは裁量を持たず、ユーザーの権限の範囲で動く。例：「自分の提案書を仕上げてほしい」 業務の依頼：任された側にも裁量がある。エージェント自身の権限と判断で動く。例：「組織内の情報整理を定期的に行ってほしい」 例えば、「エージェントは自分の権限で動いてくれた方がアクセス範囲やできることが明確」である、という意見もありますし、一方で「誰が実行しても同じ結果が得られるようにエージェントごとに権限が管理が理想」という意見もあります。 ユースケースによってどちらも妥当そうに見えます。どちらをやるにしても一つのプロダクトの中でどう表現し、どう実現できるのか、はまだぼんやりしています。 なお、代行だからといって「ユーザーの全権限をそのままエージェントに渡してよい」わけではありません。本人なら許される操作でも、エージェント経由だと意図しない結果になることがあります（機密情報や受領資料を外部に送信してしまったら、目も当てられません）。代行であっても「どの権限を、どの操作に限って貸すか」の絞り込みは必要です。 2. そのエージェントは「誰のもの」か 2つ目は、論点1とは別の軸で、**そのエージェントが「誰に紐づくアイデンティティなのか」**という話です。 個人に紐づくエージェント：自分の業務のために使うエージェント。誰に許可を取ればよいかが明確で、説明責任もその人に集約されるため、シンプルで安心しやすい。一方で、異動や退職のたびに引き継ぎが発生します。 組織に紐づくエージェント（脱属人化）：チーム全体に向けて働く、共通リソースとしてのエージェント。特定個人がいなくなっても残せますが、「誰が責任を持ち、誰が許可を出すのか」を明確にする必要がある。 1つ目の代行・依頼と、この2つ目の誰のものか、は2軸として独立しているかもしれないと考えています。「代行か依頼か（権限の出どころ）」と「個人か組織か（アイデンティティの所在）」は、同じ話に見えますが、たとえば組織に属するエージェントが、実行時には指示者の権限を借りて代行するといった組み合わせも成り立ちます。混同せず別々の話として設計したほうが、選べる形が広がりそうです。 3. リソースをどう安全に分けて扱うか 3つ目は、エージェントが触れるリソースの範囲をどう引くかです。 エージェントを特定のプロジェクト資料やアクションに限定すると、安全性は高まりますが、その範囲でしか動けず、汎用性や、応用力は下がります。 一方で、プロジェクトを横断・俯瞰したい場面も当然あります。 目的によってエージェントが触れる範囲を限定したくなります。 リソース範囲ごとにエージェントをそれぞれ用意する形になるかもしれませんし、用途に応じたスコープを柔軟に構成できると良いのかもしれません。また、用途に応じたエージェントを実行できる主体も異なる形にする必要があるかもしれません。 これらはどれも「最終的には全部必要」という話に着地するかもしれません。 さまざまなユースケースをカバーしたい我々のようなプロダクトでは、汎用性とカスタマイズ性を両立しながら、作り手もユーザーも安心・安全に使いこなせる権限モデルを確立する必要があると考えています。 未来？：権限管理はどこへ向かうのか 足元の課題を解くのはもちろんですが、もう少し先を妄想してみたいと思います。 権限は「リソースの列挙」から「意図・条件の記述」へ 「どのファイル」「どのフォルダ」と一つずつ指定するのではなく、「機密区分が高くないもの」「この案件に関するもの」のように、条件や意味で権限を切り分ける 方向に進むかもしれません。エージェントは大量かつ多様なリソースを必要とするため、人間が一つずつACLを設定する運用はいずれ破綻してしまいそうです。クエリのようなスコープや、属性ベースのポリシーが中心になっていくのではないでしょうか。 権限は連鎖し、その連鎖は検証可能になる 人→エージェント→別のエージェント→外部API、というように多段の依頼や権限委譲が当たり前になりつつあります。各ホップでトークンが渡され、最終的に「誰の意図で、どのエージェントが、何をしたか」を正確に辿れる状態が求められます。複雑な流れであってもアカウンタビリティが保てること自体が、権限設計の要件になっていくはずです。 エージェントは「管理されるアイデンティティ」になる 人が会社に入社・退社する際、アカウント発行、PCセットアップ、アカウント削除、PCリセットといった手続きがあります。同じように、エージェントにも作成・更新・廃棄のライフサイクルが必要になりそうです。「いま組織にどんなエージェントがいて、何ができ、最後にいつ何をしたか」を把握できる状態が、ガバナンスの前提になっていくでしょう。 組織の中で働くエージェントが本当の意味で安心・安全になるには、さまざまな工夫が必要であると思います。 さいごに ここまで、権限管理を「過去／現在／未来」の時間軸で整理してきました。 いまこの論点を考える意味は、エージェントが便利な新機能ではなく、組織の中で意思決定とアクションを連続的に生み出す「新しい行為者」になりつつあるからだと思っています。だからこそ、単に強い／弱い権限を付けるのではなく、次の3つをプロダクトと運用の両面で設計していく必要があります。 誰のために動いたのか どの範囲まで委ねたのか 何をしたのかを、後から説明できるのか 完璧な解はまだ見えていません。それでも、Ai Workforceなりの、「さまざま」な業務に耐える権限モデルを探っていきたいと思います。 さいごのさいごに Ai Workforceでは、プロダクトマネージャーやエンジニアを募集しています。 ご興味のある方は、ぜひカジュアル面談からお気軽にご応募ください！ jobs.layerx.co.jp
- 生成AI
- セキュリティ
- ガバナンス
AIに全力投資するLayerXでインターンしたら、実装が早すぎて設計の重要性に気づいた話
※本記事は、2026年5月までLayerXのAi Workforce事業部でSWEインターンとして活躍してくれたkawachan（かわちゃん）さんによる執筆です。本人のインターン期間終了に伴い、LayerX の koichi（こいち）が代理で投稿いたします。最先端のAI協業の現場で得られたリアルな学びを、ぜひご覧ください！ はじめに こんにちは、kawachan（かわちゃん）です。昨年の12月から、LayerXのAi Workforce事業部SWE（Software Engineer）チームでインターンをしています。 この記事では、Ai Workforce事業部への応募を検討されている方や、当事業部に興味をお持ちの方に向けて、私たちがどのようにAIを活用し、協業しながら開発を進めているのか、インターン生としての実体験を交えてご紹介します。 私の業務内容 当事業部では、FDE（Forward Deployment Engineer）やプロダクトチームのメンバーから寄せられた意見や要望が、チケットとして起票されます。 インターン生もそのチケットの中から主体的に案件を担当し、設計、実装、テストまで一気通貫で行います。私は主に、Ai Workforceの既存機能の改善や、新バージョンに向けた新規機能の開発を担当させていただきました。 AIとの協業体制 Ai Workforce事業部SWEチームでは、AIを単なる補助ツールとしてではなく、強力な開発パートナーとして位置づけています。ここでは、具体的な取り組みをいくつか紹介し、チームの魅力をお伝えします。 1. 圧倒的なAIコーディングツールへの投資 LayerXでは「Bet AI」の行動指針の通り、CursorやClaude Codeといった最新のAIコーディングツールへの投資を惜しみません。私自身、週2日の勤務であるにもかかわらず、潤沢なAI利用環境を提供していただき、その投資の大きさに驚きました。 開発現場では、AIと壁打ちをしながら案件のドメイン知識を高速にキャッチアップし、まずはプロトタイプ（叩き台）を作成してチームへ共有します。認識のズレがあればその場で即座に修正していく、という高速なサイクルが確立されています。 これによりリリース速度が飛躍的に向上し、FDEを介してお客様のフィードバックが迅速に開発チームに届くため、さらなる改善へとつながる非常に良いサイクルが生まれています。AIを用いた高速な実装力は、これからの時代の必須スキルだと身をもって実感しました。 2. AIの活用を前提としたコーディング環境（rulesの運用） AIにただコードを書かせると、チームのコーディング規約や設計方針を無視した実装になりがちで、結果としてレビュワーの負担が増えてしまいます。 この課題に対し、当事業部ではコードのドメイン知識や共通ルールをrulesというディレクトリに集約しています。AIの活用をはじめから前提として開発環境を整備している点が非常に合理的です。 AIは常にこのrulesを参照するため、チームの共通認識に沿った納得感のある実装方針を出力してくれます。また、開発メンバーは誰でも自由にrulesへ知見を追加・更新できるため、AIは常に最新のコンテキストに基づいた精度の高いコーディングを行ってくれます。 3. プルリクエスト（PR）の自動レビュー 開発の中で特に興味深かったのが、GitHubとGreptileやDevinなどのAIツールを連携させた、プルリクエストの自動レビューの仕組みです。 タスクによっては修正が500行を超える大規模なものもあり、人間によるレビュー負担が大きい場合がありました。そのような際、まずはAIが網羅的にレビューを行って細かなバグや規約の課題を潰します。これにより、人間のレビュワーはドメインロジックの妥当性やアーキテクチャの議論など、より本質的なレビューに集中できるようになりました。 4. QAガイドおよびStory Testの自動生成 開発フローは、チケット起票 → 実装 → QA（品質保証）メンバーによる検証 → 本番リリース、という順で進みます。 私が参画して1ヶ月ほど経った頃、QAメンバーに提出するための「QAガイド」をAIが自動生成する機能が導入されました。 これにより、開発者のドキュメント作成負担やQAメンバーの確認コストが軽減されただけでなく、開発者が「QAメンバーがどのような観点で検証を行っているのか」をより深く理解するきっかけになりました。結果として開発とQAの距離が縮まり、気軽に相談し合える文化がさらに強固になっています。AIには、部署間のギャップを埋め、チームの心理的距離を近づける効果もあるのだと実感しました。 インターンを通じて得た2つの大きな学び 1. 「どう作るか」より「何を作るか」の重要性 インターンを通じて最も強く感じたのは、開発現場において「これは本当に必要な機能なのか？」という本質的な議論が、技術的な実装方針の相談よりも圧倒的に多いことです。 AIの進化により、機能を作るコストは劇的に下がりました。だからこそ、「なぜ作るのか」「誰が求めているのか」「今本当に作るべきか」を深く熟考する重要性が増しています。 最近担当したタスクでも、まさにこのことを実感する出来事がありました。あるワークフロー作成機能において、「DSL（ドメイン固有言語）で定義するオブジェクト型のデフォルト値に対し、バリデーション（入力チェック）を強化する」という要件がありました。 しかし、SWEチームの社員の方々と相談し、実際の顧客のユースケースを深く検討する中で、「エラーを出してユーザーに修正を促す（バリデーションの強化）」よりも、「システム側でデフォルト値を自動補完する」方が、顧客の真の課題解決に繋がるのではないか、という議論に発展しました。 このように、言われたものをそのまま作るのではなく、「何を作り、何を解決したいのか」をチーム全体で常に問い直しています。ただがむしゃらにコードを量産するだけでは、使われない機能が増え、プロダクトの認知負荷やメンテナンスコストを高めるだけになってしまいます。FDEやビジネスサイドのメンバーと密に連携し、顧客の真の課題を捉え続けることが、今後のSWEにとって最も重要な役割になると確信しました。 2. 「AI前提の開発」における設計の難しさと、エンジニアの新しい役割 LayerXは日本でもトップクラスにAIを活用している企業ですが、それでも「AI前提の開発」は発展途上であり、新たな課題も見えてきました。 実装スピードが加速した分、設計が疎かになると技術負債が蓄積する速度も比例して早くなります。私自身、数週間前に実装した機能が開発のスピード感に追いつけず、すぐに負債化してしまう経験をしました。 AIが負債を残さず、いつでも切り離しや変更が容易なコードを書くためには、どのような設計やアーキテクチャが必要になるのでしょうか。従来のDDD（ドメイン駆動設計）などに代わる、AI時代に適した新しいアーキテクチャパターンが、今後このチームの試行錯誤の中から生まれていくのではないかとワクワクしています！ おわりに LayerXのAi Workforce事業部は、AIの可能性を最大限に引き出し、これまでにないスピード感で社会に価値を届けている非常にエキサイティングな組織です。 「AIが普及していく社会で、エンジニアとしてどう生き残るべきか」という不安を抱えている学生の皆さんにこそ、ぜひこの最先端の開発環境を体験していただきたいです。LayerXでのSWEインターンへの挑戦を、心からおすすめします。
- 生成AI
- ソフトウェア設計
- GitHub
- 生産性向上