• 【SIGNATEコンペ】(金融庁共催)第4回金融データ活用チャレンジ ~要件定義編~

    金融庁が主催する国際的なイベント「Japan Fintech Week 2026」。このイベントと連携した、非常に挑戦的なコンペティションが開催されます。

    テーマは、地域金融機関における取引先支援の高度化です。

    これまでのデータ分析コンペとは一線を画し、生成AIを単なるツールではなく「バディ(相棒)」として捉え、建設業界の実課題に挑むという実践的な内容になっています。

    本記事では、コンペの核心部分である「評価基準」を深掘りし、金融・建設の実務視点から、具体的にどのデータを参照し、どう攻略すべきかのアプローチを整理しました。

    リンク:(金融庁共催)第4回金融データ活用チャレンジ


    評価基準に対する対策(データソース活用)

    本コンペの勝敗を分けるのは、配布された評価視点をいかに深く解釈し、客観的なデータで裏付けられた指示(プロンプト)をAIに出せるかです。

    事務局から提示されている6つの評価視点ごとに、参照すべきデータソースと具体的な対策を見ていきましょう。

    1. 全体構成:過去と未来をつなぐ

    評価視点: 過去分析と未来提案の接続

    評価項目: 過去3年の財務・事業分析と、未来への成長戦略が一貫した因果関係で論理的に接続されているか。

    【対策アプローチ与信管理とベンチマーク】

    最も避けるべきは、現状分析と提案内容のチリグハグさです。
    例えば、利益率が悪いのが原因なのに、売上拡大ばかりを提案しても症状は改善しません。

    まずはAIに「デュポン分析」などのフレームワークを使わせ、ROE(自己資本利益率)が悪化している原因が、「儲ける力(収益性)」が低いのか、「資産を使う効率(効率性)」が悪いのかを分解させましょう。

    「どこが悪いか」を特定してから対策を打つことで、説得力のある提案になります。

    その際、対象企業の数値だけを見るのではなく、同規模の同業他社と比較することが重要です。中小企業庁が公開している実態調査などの統計データと比較させ、客観的な「弱点」を抽出してみましょう。

    2. 地域性:その街ならではの解像度

    評価視点: 地域特性の考慮

    評価項目: 企業の所在地(商圏、人口動態、行政施策)を踏まえ、画一的ではない地域密着型の提案ができているか。

    【対策アプローチ:オープンデータの注入】

    建設業は究極の「地産地消」ビジネスです。北海道と沖縄、都市部と過疎地では、求められる工事も経営課題も全く異なります。

    ここでは、国が提供する「RESAS」などの地域経済分析システムを活用するのが定石です。対象企業の商圏における人口推移や産業構造をAIにインプットさせてください。また、各自治体が公表している「総合計画」を参照し、今後その地域で予定されている公共事業や重点施策(防災、インフラ更新など)に絡めた提案を行うと評価が高まります。

    3. 業界特性:商流による戦い方の違い

    評価視点: 販路・商流の理解

    評価項目: 官公庁/民間、元請/下請などの販路特性を把握し、それに応じた具体的な分析・提案となっているか。

    【対策アプローチ:経審と入札制度の理解】

    公共工事が主体であれば、「経営事項審査(経審)」の評点(P点)アップが受注への生命線となります。一方で民間が主体であれば、提案力やデザイン力が問われます。

    まずは配布データから企業の立ち位置を分類させましょう。公共主体であれば、国土交通省のサイトで経審の仕組みを理解し、どの項目(財務健全性や技術職員数など)を改善すればランクアップできるかをシミュレーションさせることが有効です。

    4. 業界課題:具体的な技術トレンドへの投資

    評価視点: 近未来への対応 (GX/DX)

    評価項目: 低コスト工法、環境技術(GX)、省力化技術(DX)など、技術トレンドへの投資や対応策を提案できているか。

    【対策アプローチ:NETISの活用】

    単に「DXを推進しましょう」という曖昧な提案では響きません。

    建設業界には「i-Construction」という言葉がある通り、ドローン測量やBIM/CIM、遠隔施工といった具体的な技術が存在します。

    ここで活用したいのが、国土交通省が運用する新技術情報提供システム「NETIS」です。ここにある具体的な新技術をAIに学習させ、「この企業の規模と工種なら、この技術を導入することでこれだけのコスト削減が見込める」といった、具体的かつ専門的な提案を作成しましょう。

    5. 業界課題:2024年問題と人手不足

    評価視点: 需要減退・人材不足対応

    評価項目: 工事需要の変化や深刻な人手不足(2024年問題、外国人材受入等)に対し、実効性のある解決策(歩掛管理の高度化、採用・定着策等)を示せているか。

    【対策アプローチ:制度の正確な理解】

    建設業において、人の数は売上の上限に直結します。特に「2024年問題(時間外労働の上限規制)」への対応は必須です。

    厚生労働省の特設サイトで規制の詳細を確認し、違反リスクを洗い出しましょう。また、人手不足解消の切り札として「特定技能外国人」の受け入れを提案する場合は、出入国在留管理庁の資料を参照し、受け入れ可能な職種や手続きのロードマップを提示すると説得力が増します。

    6. AI活用:相棒としての創造性

    評価視点: AI活用(最終選考のみ)

    評価項目: 生成AIの特性を理解し、独自の視点や創造的なアプローチ(プロンプトの工夫等)により提案書の品質を高めているか。

    【対策アプローチ:ガイドライン準拠と創造性】

    最後に問われるのは、AIの使い方そのものです。

    AIに「金融コンサルタント」「建設業界のアナリスト」「地元商工会議所の担当者」など、複数の役割を与えて議論させるような工夫を取り入れてみましょう。

    また、生成AIの利用にあたっては、日本ディープラーニング協会(JDLA)等のガイドラインを参考に、ハルシネーション(誤情報)への対策や著作権への配慮ができていることを検証レポートで示すことも重要です。


    まとめ:金融と建設のプロとして挑む

    このコンペは、データ分析のスキルを試す場であると同時に、コンサルタントとしての提案力、そしてドメインエキスパートとしての業界理解が問われるイベントです。

    上記のような公的データをAI(RAG等)に読み込ませ、事実に基づいた提案書を作成することで、他の参加者と圧倒的な差をつけることができるはずです。

    Japan Fintech Weekでの登壇を目指して、ぜひ挑戦してみましょう。

  • AIプロジェクトをNotionで管理する方法

    ―― PdM / PM のための実務設計 ――

    AIプロジェクトでは、フォルダとNotionは以下のように使い分けます。

    • フォルダ:成果物・証跡・再現性
    • Notion:進行管理・意思決定・コミュニケーション

    本記事では、

    「AIプロジェクト名」から始まる Notion ページの構成をどう設計すべきか

    を、ビジネス実務に即して解説します。


    この記事で分かること

    • AIプロジェクト1件分の Notion ページ構成(完成形)
    • 各ページの役割と「何を書くか」
    • フォルダ管理との正しい棲み分け
    • 日常運用・引き継ぎ・レビューに強い構成

    1. Notionで管理すべきもの/管理しないもの

    Notionで管理するもの

    • 進捗
    • 意思決定
    • 課題・論点
    • 会話・議事メモ
    • 状態(未着手/検討中/完了 など)

    フォルダで管理するもの

    • 納品物
    • 仕様書の正式版
    • モデル・データの成果物
    • 証跡として残すべき資料

    Notionは「生きている情報」、フォルダは「確定した資産」

    これを混ぜないのが最大のポイントです。


    2. Notionの全体構成

    トップページ名

    AIプロジェクト|案件名

    推奨ページ構成(完成形)

    以下、1ページずつ「目的」「書く内容」「使いどころ」を説明します。


    3. 各ページの役割と中身

    ① プロジェクト概要

    目的:誰でも5分で全体像を理解できる

    書くこと

    • プロジェクト目的・背景
    • 業務課題と狙い
    • 成功指標(KPI)
    • スコープ(やる/やらない)
    • 関係者(責任者・承認者)

    ポイント

    • フォルダの「00_プロジェクト概要」と内容は対応させる
    • Notionは要約、フォルダは正式文書

    ② スケジュール・進捗管理

    目的:今どこにいて、何が遅れているかを一目で把握

    書くこと

    • フェーズ一覧(要件定義/設計/開発/検証/納品/運用)
    • マイルストーン 各タスクのステータス(未着手/進行中/レビュー中/完了)
    • 担当者

    使いどころ

    • クライアントとの進捗共有
    • 社内定例の進捗確認

    ③ 要件・仕様管理

    目的:認識ズレを防ぎ、判断軸を固定する

    書くこと

    • 業務要件(要点のみ)
    • AI要件(提供価値)
    • 前提条件・制約 仕様変更ログ(いつ・なぜ変えたか)

    重要

    • 「なぜこの判断をしたか」を必ず残す
    • 詳細仕様はフォルダにリンク

    ④ 課題・リスク管理

    目的:問題を早期に可視化し、属人化を防ぐ

    書くこと

    • 課題内容
    • 影響範囲(品質/スケジュール/コスト)
    • 対応方針
    • ステータス
    • 担当者

    典型例

    • データ欠損が多い
    • 想定精度に届かない
    • クライアント判断待ち

    ⑤ 会議・意思決定ログ

    目的:あとから「なぜそうなったか」を説明できる状態にする

    書くこと

    • 会議日付
    • 議題
    • 決定事項
    • 保留事項
    • 次アクション

    強い理由

    引き継ぎ・炎上時・監査対応で最も価値が出る

    ⑥ 納品・成果物リンク集

    目的:成果物の所在を迷わせない

    書くこと

    • フォルダ(SharePoint / Drive 等)へのリンク
    • 納品物一覧
    • バージョン
    • 納品日

    注意

    Notionにファイルを直接溜めず、あくまで「リンク集」。

    ⑦ 運用・改善管理

    目的:納品後もAIを使い続けられる状態にする

    書くこと

    • 運用ルール(誰が・いつ・何を見るか)
    • モニタリング指標
    • 改善アイデア・要望
    • 再学習や改修の検討ログ

    ポイント

    運用が始まると、ここが一番使われる

    ⑧ アーカイブ

    目的:終了後も判断履歴を残す

    書くこと

    • 完了済みタスク
    • 終了した議論
    • 過去フェーズの情報

    運用

    基本は参照のみ 編集禁止でもOK


    4. フォルダ管理との正しい棲み分け

    Notionはハブ、フォルダは保管庫


    5. PdM / PM がやるべき初期セットアップ手順

    • 「AIプロジェクト|案件名」ページを作成
    • 上記8ページをすべて作る(中身は空でもOK)
    • プロジェクト概要だけは最初に埋める
    • 定例MTGの議事メモを必ず Notion に残す
    • 週1回、課題・進捗ページを更新する

    これだけで プロジェクトの透明性が一気に上がります。


    6. よくある失敗と対策

    • ❌ Notionに資料を全部置く → ⭕ フォルダへのリンクだけ置く
    • ❌ ページが増えすぎて迷子 → ⭕ プロジェクト単位で1トップ構成にする
    • ❌ 更新されなくなる → ⭕ 定例会のアジェンダをNotion固定にする

    7. まとめ

    AIプロジェクトの成功は、

    モデルの性能より「管理の設計」で8割決まる

    と言っても過言ではありません。

    • フォルダ:会社の資産として残す
    • Notion:プロジェクトを前に進める

    この2つを分けて設計できれば、

    PdM / PM としての再現性は一気に高まります。


    AIプロジェクト用Notionテンプレ

    ※必要に応じて、テーブル部分を選択して右上メニュー → 「変換」→「データベース」にすると管理が楽になります(Tasks は Board、Issues は Table など推奨)。


    AIプロジェクト

    ステータス:(未着手 / 進行中 / 停滞 / 完了)

    プロジェクトリード:

    クライアント / 事業部:

    主要KPI(Success Criteria):

    主要マイルストーン:

    M1:要件合意(YYYY-MM-DD)

    M2:PoC完了(YYYY-MM-DD)

    M3:本番リリース(YYYY-MM-DD)


    目次

    • プロジェクト概要
    • スケジュール・進捗
    • 要件・仕様
    • 課題・リスク
    • 会議・意思決定
    • 納品・成果物
    • データカタログ
    • モデル仕様
    • 運用・モニタリング
    • アーカイブ

    プロジェクト概要

    目的(1行):

    背景(要点):

    期待効果 / ビジネスインパクト:

    スコープ(やること):

    除外事項(やらないこと):

    関係者(役割・承認者):

    • プロジェクト責任者(承認):
    • PdM / PM(運営):
    • データエンジニア:
    • データサイエンティスト:
    • 業務担当(利用者):

    スケジュール・進捗— タスク管理

    推奨フィールド:タイトル / ステータス(Backlog・Todo・In Progress・Review・Done) / 担当者 / 期日 / 重要度 / 関連(リンク)

    運用ルール:週次(または定例)でステータス更新。PdMが週1でレビューして未更新項目をピックアップする。


    要件・仕様

    業務要件(要約):

    • 目的・現行フロー(簡潔に) AI要件(提供価値):
    • 何を出力するか / どう使うか(例:来週の客数予測、CSVで提供、店舗別) 成功基準(Acceptance / KPI):
    • 例:来週の客数を±10%以内で把握できること(責任者:○○) 制約:データ、法務、時間、予算など

    課題・リスク

    推奨フィールド:ID / 課題タイトル / 種別(課題/リスク) / 影響範囲 / 優先度 / 状態 / 担当 / 対応期限 / 対応方針

    運用ルール:新課題は即登録。重大リスクは週次でエスカレーション(誰に報告するかを明記)。


    会議・意思決定ログ

    会議テンプレ(コピーして使用)

    会議名:

    日時:

    参加者:

    アジェンダ:

    1.

    2.

    決定事項:

    D-001:決定内容(責任者、期限) 保留事項: アクション: タスク(担当/期日)

    ルール:議事録は会議終了24時間以内に記載。決定事項は Decisions に要約して記録(ID付与)。


    意思決定

    ID

    日付

    決定事項

    影響範囲

    決定者

    参照会議

    D-001

    2026-01-30

    PoCは手動運用で検証する

    運用方式

    事業責任者A

    MTG_2026-01-29


    納品・成果物

    ここにはフォルダ(共有ドライブ)へのリンクを並べる(Notion内にファイルを置かない)

    納品一覧

    • v0.1_PoC出力(リンク) — 2026-02-21
    • v1.0_本番出力(リンク) — 予定日:2026-03-31
    • 利用ガイド(リンク)
    • 受け入れ基準(リンク)

    運用・モニタリング

    運用フロー(要点):

    • 日次:データ受領確認(担当:)
    • 週次:モデル指標確認(担当:)
    • 月次:精度レビュー(PdM/PMと業務担当)

    モニタリング指標(例):予測誤差(MAE)、データ欠損率、出力件数、利用頻度

    インシデント対応フロー:発見→暫定対応→影響調査→恒久対策→報告(誰へ)

    再学習計画:条件(例:MAEが閾値超過、データ量がX%増加)/手順の要約へのリンク


    アーカイブ

    • 完了済みタスクの要約
    • 廃止モデルの理由と参照先
    • 過去の重要決定のログ (参照専用。編集は制限推奨)

    便利なテンプレ

    ミーティング議事録テンプレ

    会議名: 日時: 参加者: アジェンダ: 1. 2. 決定事項: - D-XXX: (短い説明) — 決定者:/期限: アクション: - [ ] タスク名 — 担当: — 期日:

    意思決定テンプレ

    ID:D-XXX 日付: 決定内容(短文): 背景(要点): 影響(スコープ): 決定者: 参照(会議名/ドキュメント): フォローアップ(アクション/担当/期日):

    課題テンプレ

    ID:I-XXX タイトル: 種別(課題/リスク): 詳細: 影響範囲: 優先度(高/中/低): 状態(Open/In Progress/Resolved): 担当: 対応期限: 対応方針: 履歴:

    引き継ぎチェックリスト

    - [ ] プロジェクト概要を読む(00_プロジェクト概要) - [ ] AI要件を確認(01_要件定義) - [ ] 出力仕様を確認(02_設計) - [ ] モデル仕様を確認(04_モデル) - [ ] 運用フローを読む(06_運用) - [ ] 現在の重要課題(Issues)を把握 - [ ] 引継ぎ完了日を記載して署名

  • AIプロジェクトのフォルダの作成方法

    ―PdM/PM が会社資産として残すための実務手順 ―

    AIプロジェクトは「モデルが動いたら終わり」ではありません。

    重要なのは、誰が見ても分かり、引き継げる状態でプロジェクトを保存することです。本稿は、ビジネス実務者(PdM/PM/事業責任者)が主体となってプロジェクトフォルダを設計・運用するための手順を解説します。


    本ブログで得られること

    • 会社に残すべきフォルダ構成
    • 各フォルダに必ず置くべきドキュメントとその目的
    • 運用ルール(命名規則、権限、バックアップ)
    • 引き継ぎチェックリストとガバナンスの運用方法
    • よくある失敗と対策

    1. 設計方針(最初に決めるべき考え方)

    • 業務ファースト:何のためのAIなのか(誰が何をどう改善するか)を起点にする。
    • 可視化・説明責任:判断根拠と意思決定の履歴を残す。
    • 再現性:将来の改善や再現ができることを前提にドキュメント化する。
    • 運用前提:納品=終わりではなく、運用・監視・改善までを設計する。

    これらの設計方針を書面で固定してからフォルダを作成します。


    2. 推奨フォルダ構成

    まずトップレベルの名前は「AIプロジェクト_案件名」として下記構成を推奨します。

    • 00_プロジェクト概要
    • 01_要件定義
    • 02_設計
    • 03_データ
    • 04_モデル
    • 05_納品物
    • 06_運用
    • 99_アーカイブ

    各フォルダの役割は次節で詳述します。命名は日本語で統一し、並び順が自然にプロジェクトの時系列(概要→要件→設計→実装→納品→運用→履歴)になるようにします。


    3. 各フォルダに入れるべきもの

    00_プロジェクト概要

    目的:

    初めて触る人が1分で理解できる要約を置く場所。

    必須ドキュメント:

    プロジェクト概要(目的・背景・期待効果)、成功条件(業務KPI)、スコープ(やらないこと明示)、関係者一覧(責任者・承認者・連絡先)、ロードマップ(主要マイルストーン)。

    使い方:

    キックオフ資料として常に最新版を置く。主要変更は履歴を残す。

    01_要件定義

    目的:

    クライアント/事業側の要求を業務に効く形で固定する。

    必須ドキュメント:

    業務要件(現状フロー・課題)、AI要件(何を提供するか、提供しないこと)、成功基準(KPI の数値や採用判定基準)、制約(データ・法務・予算・期限)。

    使い方:

    実装や評価がブレたらここに立ち戻り、判断軸として参照する。

    02_設計

    目的:

    実装チームが迷わず作業できる設計を残す。

    必須ドキュメント:

    システム構成(図)、入出力仕様(誰がどの形式で受け取るか)、運用前提(バッチ頻度、遅延許容)、UI/レポート仕様(画面や帳票のサンプル)。

    使い方:

    実装前の合意書。設計変更は差分を明記。

    03_データ

    目的:

    データの由来・定義・問題点を誰でも追える状態にする。

    必須ドキュメント:

    データ一覧(ソース・更新頻度・保存場所)、データ定義(カラム説明・単位)、前処理ルール(欠損・外れ値の扱い)、データ課題ログ(発見→対応履歴)。

    注意点:

    個人情報や機微情報の扱いは法務ポリシーに従うこと。

    04_モデル

    目的:

    モデルの選定理由・性能・制約を業務側が理解できる形で残す。

    必須ドキュメント:

    モデル仕様(目的・入力・出力・想定利用)、評価レポート(評価指標と解釈、限界)、再現手順(誰でも同じ結果をたどるための概要)、依存関係(環境の要点)。

    使い方:

    モデル更新・再学習の根拠と履歴管理に使う。

    05_納品物

    目的:

    クライアントが業務に取り入れられる形で成果を届ける。

    必須ドキュメント:

    納品サンプル(出力例)、利用ガイド(業務担当者向け操作・解釈ルール)、受け入れ基準。

    使い方:

    契約上の検収資料・利用トレーニングに使用する。

    06_運用

    目的:

    納品後もAIが安定して使われるための運用設計を置く。

    必須ドキュメント:

    日常運用フロー(誰がいつ何をチェックするか)、モニタリング指標(主要KPI・データ品質指標)、再学習計画(トリガー条件、頻度)、障害履歴(インシデントログ)。

    運用ルール例:

    週次チェックの担当・頻度を明示する(例:毎週月曜に○○が指標確認)。

    99_アーカイブ

    目的:

    過去の判断や旧仕様を保存し、理由を辿れるようにする。

    必須ドキュメント:

    旧仕様、廃止モデル、過去の議事録・意思決定メモ。

    運用:

    アーカイブは読み取り専用にする・削除は管理者承認にする。


    4. 実務上の運用ルール(PdM/PM が決めるべき事項)

    • 保存場所の決定:会社の標準共有領域(例:SharePoint/Google Drive/Box)を使用。コードは別にGit管理する運用方針を明記。
    • アクセス設計:編集権限はコアメンバーに限定。閲覧は広め。重要操作(削除など)は管理者承認。
    • 命名規則:ドキュメントは「YYYY-MM-DD_内容_vX.Y」の形式で保存。ファイル名に日付を必須化。
    • ファイル形式:ドキュメントは Markdown(.md)か PDF、表は Excel。理由:差分と検索性。
    • 変更管理:主要ドキュメントの更新は「変更履歴」を残す。大きな設計変更は承認フローを通す。
    • バックアップ:重要フォルダは週次でスナップショットを残す。
    • オンボーディング:新担当向けチェックリストを整備(後述)。
    • 遵守事項:個人情報保護、契約・法務の制約は必ず添付して運用する。

    5. 引き継ぎ・オンボーディングチェックリスト(必須)

    新しい担当者が来たときの「初日5分チェック」:

    • 00_プロジェクト概要の「プロジェクト概要」を読む(目的・KPI・スコープ)
    • 01_要件定義の「AI要件」で期待されるアウトカムを確認
    • 02_設計の「出力仕様」を確認(納品物の形式)
    • 04_モデルの「モデル仕様」で利用上の制約を把握
    • 06_運用の「運用フロー」で定常作業を把握(週次・月次の担当)

    引き継ぎ完了時は「引継ぎ完了チェックリスト」に担当者名と日付を記録しておく。


    6. よくある失敗パターンと対策(実務の教訓)

    • READMEだけ作られて中身が空 → 対策:必須ドキュメント一覧を定義し、未完はTODOラベルを付けて週次で消化する。
    • データが担当者PCに散在 → 対策:生データは必ず会社クラウドへ。手元にある場合のルールを明示(消去・転送手続き)。
    • コードはあるが実行環境が不明 → 対策:依存関係や実行手順は必須欄にする。運用担当が実行できるレベルの要約を付ける。
    • 運用ルールがないため納品後放置 → 対策:運用フローを納品条件に含め、検収時に運用トレーニングを実施。
    • 誰が意思決定するか不明 → 対策:関係者一覧に「意思決定者」「承認者」を明記し、意思決定フローを図示する。

    7. すぐ使える短縮チェックリスト(PdM/PM 用:今すぐやること)

    1. プロジェクトルート(AIプロジェクト_案件名)を作る(共有領域上)
    2. 00_プロジェクト概要に「プロジェクト概要」「関係者一覧」「ロードマップ」を置いてチームに通知
    3. 01_要件定義に「業務要件」「AI要件」を入れてクライアント承認を得る
    4. 02_設計に「出力仕様」を入れて、業務側とサンプル出力で確認
    5. 06_運用に「週次チェック項目」と担当者を決める
    6. 引き継ぎチェックリストを作り、リポジトリに置く

    これだけでプロジェクトの透明性は大きく改善します。


    8. 提案(PdM/PM の運用改善アクション)

    • 毎週の短い「ドキュメント・デッドライン」を設定(例:水曜17:00に週次更新)。
    • 月次でドキュメント監査(未完リストを確認・割当)。
    • 重要ドキュメントはレビュー承認者を決める(臨時変更は承認必須)。
    • 初回納品時に「運用トレーニング」と「操作マニュアル」を必須で実施させる。

    9. まとめ(ビジネスでの価値)

    フォルダを作ること自体は簡単です。しかし真の価値は、そのフォルダが組織で使われ続け、引き継がれることにあります。PdM/PM は「フォルダ作成者」ではなく「フォルダを生きた資産にする人」。まずは「プロジェクト概要」を完成させてチームに共有することを今日のアクションにしてください。

  • AIプロジェクトの納品物って?

    前ブログに続いて、今回はAIプロジェクトのPdM / PM が抑えるべき納品物について書きます。

    今回もchatGPT先生にご意見いただきました。


    ― PdM / PM が最初に押さえるべき観点 ―

    AIプロジェクトの納品物は3種類

    AI案件の納品物は、大きく分けて以下の3つです。

    1. 意思決定者向けの納品物(業務で使うもの)
    2. 運用・保守のための納品物(継続させるもの)
    3. 技術的な納品物(再現・改善するもの)

    PdM / PM は、

    この3つが揃っているかを常に確認する役割です。


    ① 意思決定者向けの納品物(最重要)

    1. AIのアウトプット(画面・帳票・API)

    最も重要なのは、

    AIの結果そのものです。

    • 予測値・スコア
    • 推奨アクション
    • リスク判定結果 など

    ここで重要なのは、

    精度よりも「使える形」になっているかです。

    例:

    • CSVで渡すのか
    • BIツールで見るのか
    • 管理画面で確認するのか

    2. 利用ルール・判断ガイド

    AIは「参考情報」であることが多いです。

    そのため、

    どう使うかのルールが必須になります。

    • この数値が出たらどう判断するか
    • 使ってはいけないケース
    • 人が最終判断すべきポイント

    これがないと、

    「結局使われないAI」になります。


    ② 運用・保守のための納品物

    3. 運用フロー・業務手順書

    誰が いつ 何を確認し どう対応するか

    AIを組み込んだ後の業務フローを明文化します。

    PdM / PM が関与しないと、ここが抜け落ちがちです。


    4. モニタリング指標・運用KPI

    納品して終わり、ではありません。

    • 精度は劣化していないか
    • データは正常か 利用されているか

    最低限、以下は定義します。

    • モデル評価指標
    • データ異常検知
    • 利用頻度

    ③ 技術的な納品物(現場向け)

    5. 学習・推論コード一式

    • 学習コード
    • 推論コード
    • 設定ファイル

    「誰が見ても再現できる状態」

    になっていることが重要です。


    6. データ定義・前処理仕様

    • 使用データ一覧
    • カラム定義
    • 前処理ルール

    ここが曖昧だと、将来の改善が止まります。


    7. モデル仕様書(軽量でOK)

    数十ページの立派な資料は不要です。

    最低限、

    • モデルの目的
    • 入力データ
    • 出力内容
    • 制約・注意点

    これだけで十分です。


    フェーズ別:納品物の対応関係


    PdM / PM が見るべきチェックポイント

    • クライアントは「使い方」を理解しているか
    • 運用担当が困らない状態か
    • 技術的にブラックボックス化していないか

    まとめ

    AIプロジェクトの納品物とは、

    AIモデルそのものではありません。

    「業務で使い続けられる状態」

    それ自体が納品物です。

    PdM / PM の価値は、

    この全体像を設計できることにあります。


    いいですね。

    今回に関しては、自分の想像を超えない範囲でした。

    いかかでしたでしょうか?

    前回の記事とあわせて読むことで、

    仕事の進め方から納品物まで

    AIプロジェクトの全体像がひと通り見えたのではないかと思います。

    AIプロジェクトは、作って終わりではなく、開発と運用のサイクルで改善され続けてはじめて意味があります。

    そのために、PdM / PM が何を考えて用意していくべきか。

    この記事が、これからAIプロジェクトに関わる方のご参考になれば幸いです。

  • AIプロジェクトのPdM/PMを任された人が、最初に読むべき実践記事

    AIプロジェクトの

    プロダクトマネージャー(PdM)兼プロジェクトマネージャー(PM)

    を任されました。

    クライアントの要望を整理し、

    AIプロダクトの開発を進め、

    進捗を共有し、課題を洗い出し、

    チームに仕事を割り振る。

    ……頭で断片的に理解していても、何に注意して動いて行けばいいかわからない笑。

    この記事では、

    AIプロジェクトで破綻しないための仕事の進め方を、実務目線で整理します。

    はい、僕向けです 笑。

    読者様も、同じ経緯でこの記事に思うので、少しでも参考になれば幸いです。

    (以下、僕の強い味方であるchatGPT様のご意見です。)


    AIプロジェクトのPdM兼PMは難易度が高いですが、型を持てば一気に楽になります。

    あなたのこれまでの データ・ML実務(LightGBM ) の経験は、かなり武器になります。

    以下は「明日からこの順で動けば破綻しない」実践フレームです。


    全体像(まずはこれを頭に入れる)

    あなたの役割は 3つの翻訳者 です。

    その1. クライアントの曖昧な要望 を 解ける問題 に翻訳

    その2. 解ける問題 を AIプロダクトの仕様 に翻訳

    その3. 仕様 を チームの具体タスク に翻訳

    この翻訳がうまくいけば、進捗・信頼・成果がすべて回ります。


    ① 最初にやるべきこと(着任直後)

    1. ゴールを「ビジネスKPI」で固定する

    AIの精度ではなく、意思決定に使えるかが基準です。

    必ず決める質問

    • このAIで「何を良くしたい?」(売上?工数?リスク?)
    • 誰が、いつ、どの判断に使う?
    • 使えなかったら何が困る?

    👉 例(良い形)

    「週次の発注量を決める担当者が、

    来週の客数を±10%以内で把握できること」

    ※ 精度目標(RMSEなど)は後で決める

    2. 「やらないこと」を決める(超重要)

    AI案件は膨張するのが失敗パターン。

    • 今回は 自動化しない
    • 今回は リアルタイムはやらない
    • 今回は 全店舗対応しない

    👉 これを最初にクライアントと合意


    ② クライアント要望 → プロジェクト設計

    要望整理テンプレ(そのまま使えます)

    ① 背景・課題 ② 期待しているアウトカム(業務レベル) ③ 現在の業務フロー(AIなし) ④ AIが入るポイント ⑤ 成功条件(定量・定性) ⑥ 制約(期限 / データ / 予算 / 法務)

    これを1枚にまとめて、

    👉 「この理解で合ってますか?」レビューを必ず入れる。

    AIプロジェクト特有の注意点

    最初に確定できないもの

    • 精度
    • 学習に使えるデータの質
    • 特徴量の有効性

    だからこそ👇

    「段階的に確度を上げる前提」をクライアントに説明


    ③ スケジュールの作り方(鉄板)

    AI案件の王道フェーズ

    Phase 0:業務理解・データ棚卸(1〜2週)

    • 使えるデータは何か
    • 欠損・粒度・履歴
    • 業務的に「使えない」値は?

    👉 この時点で赤信号が出る案件は多い

    Phase 1:PoC(まずは動くもの)(2〜4週)

    • 精度より「方向性」
    • シンプルなモデル(線形 or LightGBM)
    • 手動運用OK

    👉 クライアントには

    「これは検証用です」と明言

    Phase 2:業務で使える形へ(4〜8週)

    • 特徴量改善
    • 精度評価
    • UI / 出力形式調整
    • 運用ルール作成

    Phase 3:本番・改善サイクル

    モニタリング 精度劣化検知 再学習計画


    ④ 進捗共有・クライアントとの会話術

    進捗報告は「事実+判断」

    ❌ 悪い例

    「精度が思ったより出てません」

    ⭕ 良い例

    「現状、祝日影響が強く残っています

    → 特徴量追加で改善見込みあり

    → 1週間追加で検証したいです」

    毎回伝える3点セット

    • 今どこ?(事実)
    • 何が課題?(仮説)
    • どうする?(選択肢)

    👉 クライアントに「決断」をしてもらう


    ⑤ チームへの仕事の渡し方

    タスクは「判断不要レベル」まで落とす

    ❌「特徴量を考えて」

    ⭕「祝日影響を見るために・祝日前後±3日のフラグ・曜日×祝日交互作用を作って、CVで比較して」

    役割分担の基本

    あなた:全体設計・判断・対外調整

    ML:モデル・特徴量・評価

    DE:データ整備・パイプライン

    Biz:業務要件・使い勝手


    ⑥ あなたが毎週やるべきチェックリスト

    1. クライアントの期待はズレていないか?
    2. 「精度」ではなく「使えるか」を見ているか?
    3. 次の意思決定は誰がするのか明確か?
    4. チームは迷わず作業できているか?

    最後に(かなり重要)

    あなたは

    「AIを作る人」ではなく

    「AIで失敗させない人」です。

    技術力よりも

    • 問題設定
    • 期待値調整
    • 意思決定の整理

    ここができるPdM/PMは本当に希少です。


    ・・・。

    GPT先生さすがです…とても勉強になりました。

    自分の担当するプロジェクトでも、当てはまる課題も共通していて、とても共感しました。

    今後は PdM/PMとして、

    プロジェクトの進行は①〜③を、

    プロジェクト進行中に④〜⑥を

    参考にしたいと思いました。

    次のブログでは、前職が製造業界で、仕事の完了=納品を意識していた関係で、

    プロジェクトでの成果物/納品物って何?

    と気になったので、それについて書きます。

  • 仕事で使える便利ツール(自分用メモ)

    ※随時更新

    目新しいものは、ないと思われます!

    ご了承下さい🙇

    必須級

    Claude

    コード最強、要求を完璧に受け止めつつ、更に上質なコードを提供してくれる。

    Gemini

    回答の表現がいい。メール文章を依頼するのに重宝します。

    chatGPT

    普段使い。気軽に頼める。

    Notion

    プロジェクト管理

    資料作成向け

    NotebookLM

    たまに文字おかしいけど、普通に優秀。まだ使いこなせてない感。

    gen-sperk

    編集可能なスライドを作ってくれる。細かい修正も◎

    Manus

    高性能。ただ、クレジットが秒でなくなる。

    アーキテクチャ設計向け

    Draw.io

    システム構成図・データフロー図作成。ベースはアーキの得意なGPTに質問してXML形式で出力。

    コード・データ分析向け

    Google Colab

    検証から開発も出来る。GPUもある。

    VS Code

    データの修正とか?最近はあまり使わないかも。

    クリエイティブ

    Google studio

    あまり使ってないけど、簡単なアプリなら作れるらしい。

  • 【実装ガイド】Dataiku Cloudで作る R&D Value Navigator

    前提

    1. Dataiku DSS 14 の管理者アカウント(プラグイン、LLM接続、Agent Hub の設定で必要)

    2. プロジェクト作成権限と Managed Folders 作成権限

    3. LLM API キー(OpenAI 等)を Dataiku に登録済み(Agentが使う場合)

    4. Code env(プロジェクト)に以下パッケージをインストールしておく(Designer/Modeler/Reporter 用):

    pandas, numpy, scipy, statsmodels, pyDOE2, scikit-learn, lightgbm, shap, python-pptx, matplotlib, dataiku

    構成の要点

    データフロー(raw_* のデータ群→前処理→feature→ROI/score→agent用ビュー)を Dataiku Flow として再現し、その上に Visual/Code Agent を配置して Agent Hub / Agent Connect で研究者がチャット操作できるようにします。

    目次

    1. データセット(名称とスキーマ)

    2. Flow:レシピ(SQL / Prepare / Group / Join)一覧と実装コード

    3. Agent 用ビュー(SQL) — agent_historical_search 等

    4. Code Agent 実装(Experiment Designer / Simulation / Modeler / Reporter) — Dataiku 用 process() コード

    5. Visual Agent(Historical / Knowledge)設定(Agent Tools / Prompt)

    6. Agent Hub & Agent Connect 設定手順(Intent / Conversation profile)

    7. テスト手順 & デバッグチェックリスト

    8. 付録:よく使う Dataiku 操作のショートカット

    1. データセット — 作成しておくもの

    • raw_employees.csv employee_id, role, annual_cost
    • raw_projects.csv project_id, project_title, start_date, end_date, status, project_lead
    • raw_labor_hours.csv labor_id, employee_id, project_id, hours, date
    • raw_expenses.csv expense_id, project_id, expense_type, amount
    • raw_products.csv product_id, project_id, product_name
    • raw_sales.csv sale_id, product_id, year, revenue
    • raw_market.csv market_id, product_id, growth_rate
    • raw_patents.csv patent_id, project_id, patent_score

    2. Flow:レシピの順番と具体的SQL / Prepare 設定

    各ステップは Flow で新規 Recipe(Prepare / Join / Group / SQL / Python)を作成して下さい。SQL は SQL レシピで実行可能です。

    2.1 labor_cost_per_project の作成

    操作:Join + Prepare

    説明:raw_labor_hours JOIN raw_employees → 労務コスト算出(hours * annual_cost / 2000)

    手順

    Join Recipe: raw_labor_hours (left) JOIN raw_employees on employee_id Prepare Recipe: 新しいカラム labor_cost を追加(式): labor_cost = hours * annual_cost / 2000

    出力 dataset:labor_cost_per_project

    2.2 labor_cost_project(プロジェクト別人件費集計)

    操作:Group Recipe

    Group by: project_id

    Aggregation:SUM(labor_cost) -> total_labor_cost

    出力 dataset:labor_cost_project

    2.3 other_cost_project(外注等の経費集計)

    操作:Group Recipe on raw_expenses

    Group by: project_id

    Aggregation:SUM(amount) -> total_other_cost

    出力 dataset:other_cost_project

    2.4 project_total_cost(総コスト)

    操作:Join labor_cost_project LEFT JOIN other_cost_project on project_id → Prepare: total_cost = total_labor_cost + total_other_cost

    出力 dataset:project_total_cost

    2.5 project_revenue(製品売上をプロジェクト集約)

    操作:Join raw_products JOIN raw_sales on product_id → Group by project_id:SUM(revenue) -> total_revenue AVG(revenue) -> avg_annual_revenue

    出力 dataset:project_revenue

    2.6 project_roi(ROI算出)

    操作:Join project_revenue JOIN project_total_cost on project_id → Prepare:

    roi = (total_revenue - total_cost) / total_cost revenue_cost_ratio = total_revenue / total_cost

    出力 dataset:project_roi

    2.7 raw_roi_summary(Success/Strategic Score算出) — PDFロジックそのまま

    操作:Join project_roi JOIN raw_patents on project_id → Prepare(SQL または Prepare)

    式(SQL 表現推奨):

    -- SQL recipe: create raw_roi_summary SELECT p.project_id, p.total_revenue, c.total_cost, ROUND((p.total_revenue - c.total_cost)/c.total_cost, 4) AS roi, r.patent_score, CASE WHEN ( (p.total_revenue - c.total_cost)/c.total_cost ) > 1.5 AND r.patent_score > 80 THEN 5 WHEN ( (p.total_revenue - c.total_cost)/c.total_cost ) > 1.2 THEN 4 WHEN ( (p.total_revenue - c.total_cost)/c.total_cost ) > 1.0 THEN 3 WHEN ( (p.total_revenue - c.total_cost)/c.total_cost ) > 0.8 THEN 2 ELSE 1 END AS success_score, ROUND( (CASE WHEN ( (p.total_revenue - c.total_cost)/c.total_cost ) > 1.5 AND r.patent_score > 80 THEN 5 WHEN ( (p.total_revenue - c.total_cost)/c.total_cost ) > 1.2 THEN 4 WHEN ( (p.total_revenue - c.total_cost)/c.total_cost ) > 1.0 THEN 3 WHEN ( (p.total_revenue - c.total_cost)/c.total_cost ) > 0.8 THEN 2 ELSE 1 END) * 0.6 + r.patent_score * 0.4, 2) AS strategic_score FROM project_revenue p LEFT JOIN project_total_cost c ON p.project_id = c.project_id LEFT JOIN raw_patents r ON p.project_id = r.project_id

    出力 dataset:raw_roi_summary

    3. Agent 用ビュー(SQL) — agent_historical_search

    目的:過去のプロジェクトを検索・類似抽出するためのビューを作成。Agent が参照します(Historical Agent 用)。

    SQL レシピ(そのまま貼れる):

    -- agent_historical_search SELECT project_id, project_title, roi, strategic_score, total_revenue, total_cost, patent_score FROM raw_roi_summary WHERE roi IS NOT NULL

    出力 dataset:agent_historical_search

    この dataset を Knowledge Bank 的に Visual Agent の「Dataset Lookup」ツールで参照します。

    4. Code Agent 実装

    以下は Dataiku Code Agent にそのまま貼れる process() の骨子です。Dataiku の Code Agent 作成時に process(inputs, outputs) を実装します(ファイル入出力は Dataiku API を使用)。

    注意:Dataiku の Code Agent 環境では dataiku モジュールが利用可能です。Managed Folder や Dataset の読み書きは dataiku.Folder / dataiku.Dataset を使ってください。

    4.1 Simulation Agent(Code Agent) — PDF準拠の NPV / IRR 計算

    # simulation_agent.py (Code Agent: process) import json import numpy as np def process(inputs, outputs): # inputs: expect json with "cashflows" (list), "discount_rate" payload = inputs.get("payload") if isinstance(payload, str): payload = json.loads(payload) cashflows = payload.get("cashflows", []) # e.g., [-1000, 300, 400, 500] discount = payload.get("discount_rate", 0.08) if not cashflows: raise ValueError("cashflows missing") # NPV npv = sum(cf / ((1+discount)**i) for i, cf in enumerate(cashflows)) # IRR (numpy.irr may be deprecated; use numpy_financial if available; fallback: np.irr) try: irr = np.irr(cashflows) except Exception: try: import numpy_financial as nf irr = nf.irr(cashflows) except Exception: irr = None outputs["simulation_json"] = json.dumps({"npv": float(npv), "irr": float(irr) if irr is not None else None})

    4.2 Experiment Designer Agent — サンプルサイズ算出(Code Agent)

    # experiment_designer_agent.py import json import math from statsmodels.stats.power import TTestIndPower import dataiku def process(inputs, outputs): planner = inputs.get("planner_json") if isinstance(planner, str): planner = json.loads(planner) # extract params or defaults baseline = planner.get("baseline", 0.2) min_effect = planner.get("min_effect", 0.05) alpha = planner.get("alpha", 0.05) power = planner.get("power", 0.8) # For proportions you'd use proportion_effectsize, but we default to Cohen's d approximation effect_size = planner.get("effect_size", min_effect) analysis = TTestIndPower() n_per_group = math.ceil(analysis.solve_power(effect_size=effect_size, alpha=alpha, power=power, alternative='two-sided')) protocol = { "design_type": "two_group_ttest", "n_per_group": n_per_group, "total_n": n_per_group * 2, "alpha": alpha, "power": power, "variables": planner.get("required_data", []), "hypothesis": planner.get("hypothesis", "") } outputs["protocol_json"] = json.dumps(protocol)

    4.3 Modeler Agent — LightGBM + SHAP(Dataiku 用。Managed Folder へ保存)

    # modeler_agent.py import json, os import pandas as pd import numpy as np import dataiku from lightgbm import LGBMRegressor from sklearn.model_selection import train_test_split import shap import matplotlib.pyplot as plt def process(inputs, outputs): # inputs: "experiment_csv_path" or Dataiku dataset name csv_path = inputs.get("experiment_csv_path") dataset_name = inputs.get("dataset_name") project_id = inputs.get("project_id", "proj_unknown") # load data if dataset_name: ds = dataiku.Dataset(dataset_name) df = ds.get_dataframe() else: df = pd.read_csv(csv_path) # target must be "measurement" per schema if "measurement" not in df.columns: raise ValueError("measurement column required") y = df["measurement"] X = df.drop(columns=["measurement"]) X = X.fillna(X.median()) X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42) model = LGBMRegressor(n_estimators=200) model.fit(X_train, y_train) preds = model.predict(X_test) rmse = float(np.sqrt(((preds - y_test)**2).mean())) r2 = float(model.score(X_test, y_test)) # SHAP explainer = shap.TreeExplainer(model) shap_values = explainer.shap_values(X_test) out_folder = dataiku.Folder("reports_folder_id") # create in Dataiku and replace ID # save shap figure plt.figure() shap.summary_plot(shap_values, X_test, show=False) shap_path = f"/tmp/{project_id}_shap.png" plt.savefig(shap_path, bbox_inches="tight", dpi=150) # write shap to managed folder with out_folder.get_writer(f"{project_id}_shap.png") as w: with open(shap_path, "rb") as r: w.write(r.read()) importance = dict(zip(X.columns.tolist(), model.feature_importances_.tolist())) analysis = {"metrics": {"rmse": rmse, "r2": r2}, "importance": importance, "plots": {"shap": f"{project_id}_shap.png"}} outputs["analysis_json"] = json.dumps(analysis)

    重要:reports_folder_id は Dataiku 内で作成した Managed Folder の ID に置換してください(Folder の設定 → Advanced → ID で確認できます)。

    4.4 Reporter Agent — pptx 生成(Dataiku Managed Folder へ保存)

    # reporter_agent.py import json from pptx import Presentation from pptx.util import Inches import dataiku def process(inputs, outputs): analysis_json = inputs.get("analysis_json") project_id = inputs.get("project_id", "proj_unknown") if isinstance(analysis_json, str): analysis = json.loads(analysis_json) else: analysis = analysis_json prs = Presentation() # Title slide slide = prs.slides.add_slide(prs.slide_layouts[0]) slide.shapes.title.text = f"R&D Navigator Report - {project_id}" # Metrics slide slide = prs.slides.add_slide(prs.slide_layouts[1]) slide.shapes.title.text = "Key Metrics" tf = slide.shapes.placeholders[1].text_frame tf.clear() tf.add_paragraph(f"RMSE: {analysis['metrics']['rmse']}") tf.add_paragraph(f"R2: {analysis['metrics']['r2']}") # Importance slide slide = prs.slides.add_slide(prs.slide_layouts[1]) slide.shapes.title.text = "Feature Importance" tf = slide.shapes.placeholders[1].text_frame tf.clear() for k, v in analysis['importance'].items(): tf.add_paragraph(f"{k}: {v}") # insert SHAP image from managed folder reports_folder = dataiku.Folder("reports_folder_id") shap_fname = analysis['plots']['shap'] # Download shap into temp file and insert local_shap = f"/tmp/{shap_fname}" with reports_folder.get_download_stream(shap_fname) as stream: with open(local_shap, "wb") as f: f.write(stream.read()) slide = prs.slides.add_slide(prs.slide_layouts[5]) slide.shapes.add_picture(local_shap, Inches(1), Inches(1), width=Inches(8)) # Save PPTX to managed folder fname = f"report_{project_id}.pptx" with reports_folder.get_writer(fname) as w: prs.save(w) outputs["report_path"] = f"{reports_folder.get_path()}/{fname}"

    5. Visual Agent の設定(Historical / Knowledge) — 手順とプロンプト

    5.1 Historical Agent(Visual Agent)作成手順

    1. Project → + → Generative AI → Visual Agent を選択

    2. 名前: Historical_Agent(説明に用途)

    3. LLM 接続: 管理者が用意した OpenAI / Claude の connection を選択

    4. Agent Tools に Dataset Lookup を追加 → dataset に agent_historical_search を指定(上で作成)

    5. Retrieval 設定: top_k = 5、スコア閾値を適宜設定

    6. Prompt / Instructions(例):

    You are Historical Agent for R&D Navigator. Given a query about a project or a new idea, search the agent_historical_search dataset and return: - top 3 similar projects (project_id, roi, strategic_score) - short summary (1-3 sentences) of why they are similar - any lessons learned (from project metadata) Output as JSON: { similar_projects: [...], summary: "...", lessons: [...] }

    この Visual Agent は PDF の Historical Agent の役割(過去事例検索)に直接対応します。

    5.2 Knowledge / RAG Agent(もし使う場合)

    • Knowledge Bank に PDF や社内の報告書をアップロードし、Embedding Search ツールを設定する。
    • Visual Agent の Tool に Knowledge Bank Search を追加し、ユーザーの問い合わせに対して参照文献を返すように設定。

    6. Agent Hub(Orchestrator)設計・設定

    6.1 Agent の登録

    Agent Hub で次を登録:

    Historical_Agent(Visual) Experiment_Designer(Code) Simulation_Agent(Code) Modeler_Agent(Code) Reporter_Agent(Code)

    6.2 Orchestrator のルール(Intent → Agent)

    例ルール(Agent Hub の routing 設定で作成):

    • Intent contains “過去” or “similar” → Historical_Agent
    • Intent contains “サンプルサイズ” or “power” or “実験設計” → Experiment_Designer
    • Intent contains “シミュレーション” or “NPV” or “IRR” → Simulation_Agent
    • Intent contains “解析” or “モデル” or “学習” → Modeler_Agent
    • Intent contains “レポート” or “報告” → Reporter_Agent

    6.3 シーケンス(Pipeline)例

    Orchestrator が Planner の出力を受け、次に Designer、次に Modeler、最後に Reporter を順に呼ぶようパイプライン定義を行う(Agent Hub の Pipeline 機能で可視化)。

    7. Agent Connect / Dataiku Answers 設定(研究者向けチャットUI)

    7.1 Agent Connect インストール(管理者)

    Plugin ストアから Agent Connect をインストール(管理者のみ)

    7.2 Conversation Profile(例)

    名前: R&D_Navigator_Profile

    説明: “研究目的を入力すると Planner→Designer→Modeler→Reporter を順に実行します”

    Profile 設定項目

    • Default Orchestrator: Agent Hub の Orchestrator(上で作成)
    • Available Agents: Historical_Agent, Experiment_Designer, Simulation_Agent, Modeler_Agent, Reporter_Agent
    • File upload enabled: yes (uploads go to inputs Managed Folder)
    • Conversation store: ON (保存先と保持ポリシーを設定)

    7.3 UI カスタマイズ(推奨)

    ファイルアップロードボタン(inputs folder) 「実行」ボタン(Orchestrator に run コマンド) 「状況確認」ボタン(projects dataset の status を表示)

    8. テスト手順 & デバッグチェックリスト

    単体テスト(Agentごと)

    • Historical Agent: 入力例「似たプロジェクトを教えて」→ agent_historical_search から3件返るか確認
    • Experiment Designer: 固定 planner_json を投げ、n_per_group が妥当か(期待値)
    • Modeler: サンプル CSV(小規模)で学習→analysis_json が返るか、plots が managed folder に保存されるか

    E2E テスト

    1. Agent Connect で converse: 「新触媒Xで歩留まりを10%改善したい。予算50万円。」

    2. Orchestrator が Planner → Designer → (ユーザー同意)→ Modeler(dummy)→ Reporter を順に実行。

    3. projects dataset の status が reported になり、reports/ Managed Folder に PPTX が生成されることを確認。

    デバッグのポイント

    • Code Agent 実行時のエラーログは Agent Hub の実行ログで取得(Stacktrace を確認)
    • Managed Folder ID の不一致 → ファイル入出力で「Folder not found」エラーが出る(ID確認)
    • LLM のレスポンスが想定外 → Visual Agent の Prompt を修正(Instruction を具体化)

    9. セキュリティ & ガバナンス(必須)

    • Managed Folder 書き込み権限は研究者/開発者のみ付与
    • LLM に送る入力は PIIや企業機密を除去するフィルタを作る(Code Agent で sanitize)
    • Conversation の保存・アクセスログを有効にし、保持期間とアクセス権を制定

    10. 付録:よく使う Dataiku 操作ショートカット(UI手順)

    • Managed Folder ID 確認:Folder → Settings → Advanced → ID
    • Code Env パッケージ追加:Project → Settings → Code env → Edit → Add packages
    • Code Agent 作成:Flow → + → Generative AI → Code Agent → Create → paste process()
    • Visual Agent 作成:Flow → + → Generative AI → Visual Agent → configure Tools & Prompt
    • Agent Hub 設定:Administration → Generative AI → Agent Hub → Create Team / Pipeline

    11. まとめ(実装の流れ・優先度)

    1. Raw datasets を Flow に追加(names/columns を PDF 準拠で)

    2. 前処理(Join / Group / Prepare)を順に作る → raw_roi_summary まで構築(SQLレシピを活用)

    3. agent_historical_search の dataset を作る(Agent 用ビュー)

    4. Managed Folders(inputs, plans, protocols, reports)を作る

    5. Code Agent(Simulation, Designer, Modeler, Reporter)を作成して process() を実装

    6. Visual Agent(Historical)を作って dataset lookup を設定

    7. Agent Hub にエージェントを登録・Orchestrator ルールを作る

    8. Agent Connect(Answers)でチャット UI を公開し E2E テスト

  • 最近、生成AIに頼めば、それっぽいブログ記事が簡単に作れるようになりました。

    文章も構成も、ある程度はAIが整えてくれる。

    情報をまとめるだけなら、人間がやる必要はほとんどなくなってきています。

    それでも、これから、自分の経験や考えを書こうと思います。

    本ブログでは、その背景・理由を書いていきます。

    生成AIは「経験」を積めない

    生成AIを使っていて強く感じるのは、

    AIは自ら経験を積むことができないという点です。

    成功体験、そこから生まれる次への挑戦。

    また、失敗によって鍛えられる判断力。

    そういったものは、実際に手を動かして、

    悩んで、試行錯誤した人間の中にしか残りません。

    だからこそ、

    僕たちが挑戦したことや、残した成果の価値は、これからむしろ高まっていく

    そんな気がしています。

    Twitter

    専門領域ほど、AIは“鵜呑み”にしてはいけない

    データ分析やAI活用の現場では、

    「AIがこう言っているから正しい」という判断は、かなり危険だと感じています。

    特に専門性の高い領域では、

    この前提は妥当か

    このデータの取り方で問題ないか

    現場の感覚とズレていないか

    といった “専門家の知見による裏付け” が欠かせません。

    AIの提案はとても便利です。

    でもそれはあくまで「仮説」や「叩き台」であって、

    最終的に責任を持って判断するのは人間だと思っています。

    企業での生成AI活用は、もっと軽くていい

    最近は「生成AIをどう業務に組み込むか」という話題をよく耳にしますが、

    個人的には、もっとライトなスタンスでいいのではないかと感じています。

    たとえば、

    根拠は完璧じゃないけど、ちょっと資料作成が楽になる

    厳密性はさておき、考えるきっかけを増やしてくれる

    仕事の心理的ハードルを少し下げてくれる

    「ちょっと働きやすさを向上させる」くらいが、ちょうどいい。

    無理にROIを出そうとしたり、完璧な設計を求めすぎると、

    AIへの印象が固くなり、かえって使われなくなることも多い気がしています。

    僕がこのブログで書いていきたいこと

    このブログでは、

    • 知っ得な技術ノウハウ
    • 技術導入・実装に向けた試行錯誤
    • ビジネスと技術の間で悩んだポイント
    • データ分析やAIを実務で使った時の所感

    そういったものを、できるだけそのまま残していきたいと思っています。

    派手な成功談よりも、

    考え方や前提の置き方を大切にしたいと思っています。

    将来やりたいこと

    将来的には、

    データサイエンスやAI技術を通じて、働く人の作業的な負担を軽減し、創造的な価値創出に意識を向けられる社会へ加速させたい

    と考えています。

    AIが人の仕事を奪うのではなく、

    人が「考えること」に集中できる環境を作る。

    そのための道具として、AIやデータ分析を使っていきたい。

    最後に

    まだ本ブログの形は定まってません!

    書きながら少しずつ方向性を見つけていくつもりです。

    AIが当たり前になった今だからこそ、

    新たな発見や考えを、自分の言葉で残す場所を持ちたい。

    そんな気持ちで投稿を続けます。