Works
「何を作るか」から「動くものを届ける」まで。
生成AI・業務システム・MVP開発・DX戦略の現場で積み上げた15件の支援実績を、課題・アプローチ・支援のポイントの3段構造でご紹介します。
守秘義務の観点から、支援先は業種カテゴリでの表記としています。
15件
公開可能なプロジェクト数
14件
うち生成AI（LLM API）組み込みを伴う案件
約90%
業務工数の最大削減率
15年
IT・新規事業領域での実務経験
求人コンテンツの制作から媒体入稿まで、複数人で行う作業が非効率で、ミスが頻発していた。専用システムの構築が急務だった。
制作〜入稿ワークフローの可視化と課題整理から着手。生成AI（LLM API）を組み込んだ制作・校閲の自動化を設計し、要件定義・画面設計からフルスクラッチでの実装までを一人で担当した。月数百件規模の運用に耐える構成とし、現場への定着まで並走した。
生成AIを組み込むことで、報告・集計業務の工数を約90%削減。月数百件規模の制作〜入稿〜校閲を自動化するシステムを、フルスクラッチで約2ヶ月で完成させた。要件定義から実装まで一人で完結させたため、仕様変更が即日反映できる体制になった。
現在のサービスでは 生成AI 業務自動化 に相当します。
採用体験を革新するプロダクトのアイデアはあるものの、「どの市場から攻めるか」「何をMVPとして作るか」が定まらず、開発着手できずにいた。
ターゲット市場の調査・競合分析と参入優先度の整理から着手。プロダクトのコアバリューとMVPスコープを定義し、要件定義書・画面仕様を整備。LLM APIを組み込んだ機能のスクラッチ実装まで一気通貫で担当した。
「作るものを決める」フェーズから参画し、そのまま実装まで同一人物が担当。要件の引き継ぎロスが発生しないため、市場調査から3ヶ月でプロダクトをリリースできた。
現在のサービスでは プロダクト開発（MVP） に相当します。
学習体験の改善を目指すプロダクト構想があったが、技術開発のリソースが不足。さらに「どこまで作ればMVPか」の判断軸も持てておらず、計画が前に進まない状態だった。
学習領域における市場トレンド・競合プロダクトを調査し、MVPに必要な機能の優先度付けと不要機能の整理を実施。要件定義・ワイヤーフレームを作成し、LLM APIを組み込んだ機能を含むスクラッチ開発の設計・実装まで担当した。
「何を捨てるか」を明確にし、限られたリソースで最大の学びが得られるMVPを3ヶ月で完成させた。
現在のサービスでは プロダクト開発（MVP） に相当します。
急成長に伴い、採用業務のオペレーションが属人化。Excelと口頭での管理が限界に達し、標準化・システム化が急務だった。
現行業務フローのヒアリングと可視化から開始。kintone導入 × スクラッチ拡張による最適アーキテクチャを設計し、業務要件を開発チームに渡せる仕様書レベルまで落とし込んだ。
kintoneで足りる範囲とスクラッチが必要な範囲を切り分け、過剰な開発費を回避。スピードと柔軟性を両立した要件定義を1ヶ月で完了した。
現在のサービスでは 生成AI 業務自動化（設計フェーズ）に相当します。
既存ツールでは業務フローに合わず、カスタム開発が必要な状況。しかし社内にエンジニアがおらず、外部への要件の伝え方もわからないという課題があった。
業務要件のヒアリングと仕様の言語化から実施。開発会社との橋渡し・RFP作成を担当し、フルスクラッチ開発の設計・実装ディレクションを行った。
社内エンジニア不在の状態から、3ヶ月で実運用へ。「事業側の言葉」と「エンジニアの言葉」を翻訳し、発注側の専門家として要件・仕様・検収基準まで整備した。
現在のサービスでは 生成AI 業務自動化 に相当します。
顧客情報が各担当者のExcelやメモに分散しており、引き継ぎや分析が困難な状態。CRMを導入したいが、どのツールを選ぶべきか・何を実現すべきかが整理できていなかった。
顧客管理の現状ヒアリングと課題の構造化から実施。自社に合ったCRMツールの選定を支援し、導入後の運用フロー設計と要件定義書の作成まで担当した。
ツール選定から運用設計まで一体で整理し、「入れたけど使われない」状態を防ぐ実践的な要件定義を実現した。
現在のサービスでは AI活用診断・設計 に相当します。
「DXを進めなければ」という意識はあるが、何から手をつければいいかわからない。社内にDXを推進できる人材もおらず、外部の視点が必要だった。
事業・業務・IT基盤の現状ヒアリングと可視化から開始。DX推進における課題の優先度付けを行い、短期・中期の実装ロードマップを策定した。
「今の現場で何が起きているか」を丁寧に拾い上げ、経営会議でそのまま意思決定できる粒度のロードマップに落とし込んだ。
現在のサービスでは AI活用診断・設計 に相当します。
求人原稿の依頼はチャットの自由文で届き、担当者がそれを読み解いて複数の掲載先それぞれの入稿フォーマットに手で転記していた。掲載先ごとに項目・コード体系・文字数制限が異なり、1件ごとの転記と確認に時間がかかるうえ、依頼文に不足項目があると往復が発生していた。
依頼文を貼り付けるだけで、生成AIの構造化出力により案件を抽出し（複数案件が混在していれば自動分割）、数十項目の案件マスタに展開する仕組みを既存の業務ツール上に構築した。不足項目はAIが補完候補を提案し、人が採否を選ぶ設計。文字数・必須項目・コード整合のチェックは生成AIではなくルールベースで機械的に判定する。掲載先の管理画面に常駐する入稿支援パネルと、転載用フォーマットの自動生成を組み合わせ、複数の掲載先への入稿を1つの画面から完結させた。
「AIが読む・書く」部分と「コードが検証する」部分を分け、入稿ミスの検出を人の注意力に依存しない構造にした。求人原稿制作システムで確立した生成AI／検証コード／人の三段構えを、流れの違う業務にそのまま横展開できることを示した事例。
現在のサービスでは 生成AI 業務自動化 に相当します。
求人原稿制作システムの稼働後、次に見えてきたのは「制作」以外の周辺業務だった。進捗は管理表を人が目で追い、停滞案件の把握が遅れる。月次の報告資料は毎月手作業で集計・作図する。依頼フォームの区分が自由記述のため、集計時に人が分類し直していた。
運用フェーズの改善を、小さな単位で継続的に納品した。管理表を動的に読み込み、KPI／ファネル／ボトルネック／案件一覧の複数ビューで日次の停滞を把握できるダッシュボードを構築。管理表から掲載件数・取引社数・生産性などを集計し、報告文と資料を自動生成する仕組みを追加。外部システムのエクスポートと管理表をIDで突合してステータス不一致を検出し、日付項目の反映まで自動化した。依頼フォームは区分を選択式に変更し、分類判定を辞書ベースで自動化。処理完了や不足情報の問い合わせをチャットへ自動投稿する通知も組み込んだ。
一度作って終わりではなく、現場の「まだ手が残っている場所」を毎月ひとつずつ潰していく運用パートナー型の関わり方。改修のたびに適用手順書と診断手順を残し、担当者が自分で運用・切り戻しできる状態を維持している。
現在のサービスでは 運用・技術パートナー に相当します。
新規開拓のために企業サイトの問い合わせフォームから営業文を送る作業を、人が1件ずつ行っていた。対象リストは大量の求人データから抽出した企業群で件数が多く、一方で「営業お断り」の企業へ誤って送ってしまうリスクや、送信結果の管理が担当者ごとにばらつく問題があった。
企業リストの取込から送信・履歴管理までを一体化したCRMを構築した。ブラウザ自動操作で問い合わせフォームを検出・入力し、ページ本文とフォームページの両方で「営業お断り」等のNGワードを検出した企業は自動でスキップ。フォーム項目の推定はキーワード辞書を基本とし、判定できなかった項目だけ生成AIで補完するハイブリッド方式とした。既定はドライラン（入力まで行い送信しない）で、実送信は明示的な指定が必要な安全設計。自動送信できなかった企業は手動送信キューに回し、コピペ支援で人が処理する。営業メンバー向けには、フォームページ上でワンクリック入力できるブラウザ拡張を別途開発し、CRMからプロファイル・テンプレートを書き出して読み込む連携と配布用の導入手順書まで整備した。
「自動で送る」ことより「送ってはいけない相手に送らない」「送った記録が残る」ことを優先した設計。完全自動化に固執せず、自動送信できない残りをブラウザ拡張と手動キューで拾う二段構えにしたことで、現場が実際に使い続けられる仕組みになった。
現在のサービスでは 生成AI 業務自動化 に相当します。
公募型の提案案件では、数十ページにおよぶ仕様書・実施要領を精読し、必須要件・評価基準（配点）・納品物・スケジュールを漏れなく拾ったうえで、提案書の骨格を組み立てる必要がある。見落としや金額の誤転記は致命的なリスクになる一方、この「読み込んで整理する」工程に時間がかかり、担当者の負担になっていた。
仕様書PDFを読み込むだけで、必須要件・評価基準・納品物・スケジュールを自動抽出し、提案書の骨格（章立てと記載方針）まで生成する仕組みを構築した。要件には仕様書原文か推定かの信頼度を必ず付与し、金額は原文をそのまま転記するルールでハルシネーションと誤記載を抑止。前年度の仕様が入手できる場合は、今年度との差分を突き合わせて発注者の意図の変化を構造化し、評価配点の重みに沿って自社の強みとの適合度を判定、対応すべきか（Go/No-Go）の材料まで提示する。最終的に要件対照表・提案書骨子・概要資料の3点を生成し、出力前にファクトチェック工程を挟む。運用初期はスプレッドシート上のスクリプトとして構築したが、その後、同じロジックをAIエージェント環境に再設計し、取引先へそのまま配布できる形にパッケージ化した。
「提案書を書かせる」のではなく「書く前の材料を漏れなく揃え、根拠を検証できる形で残す」ことに自動化の範囲を絞った。スプレッドシートのスクリプトとして始めたツールを、配布・展開しやすい構成に作り直すところまで一人で担当している。
現在のサービスでは 生成AI 業務自動化 に相当します。
案件管理はノーコード型の業務データベースで行っていたが、経営会議や関係先向けに複数の切り口（登録月別・地域別・経路別など）で件数を集計するたびに、担当者がデータを書き出して表計算ツールで組み直していた。集計の切り口が増えるほど属人化し、最新数値がすぐに出せない状態だった。
業務データベースのAPIで必要項目だけを表計算ツールに自動抽出し、その上にWebアプリとしてダッシュボードを構築した。フィルタ項目はデータ上のユニーク値から動的に生成するため、新しい区分が増えても改修不要。指標の定義を画面上で確認できるようにし、開発用のモックデータで環境を分けた。
BIツールを新たに契約せず、既存の業務データベースと業務ツールだけで完結させた。月額費用を増やさずに「いつでも最新の数字が出る」状態にすることを優先した事例。
現在のサービスでは AI活用診断・設計（データ基盤整備）に相当します。
対人スキルの研修は、講師によるロールプレイが効果的な一方、講師の稼働に依存し、受講者ごとに練習量を確保しにくい。動画型のeラーニングでは「実際にやってみる」工程が抜け落ちる。
研修プログラムをエディタで組み立て、受講者がスライド・入力・クイズ・ロールプレイ・ワークのステップを順に進めるWebアプリを構築した。ロールプレイでは、性格設定と表情アバターを持つ相手役と生成AIによる対話練習ができ、関連する理論の図解を組み込んだ。管理者向けには受講状況を把握するダッシュボードを用意し、既存のデータベースに研修用の領域を追加する形で接続した。
「教材を作る側」と「受講する側」の両方を1つのプロダクトに収め、研修事業者が自分でプログラムを増やせる構造にした。生成AIの役割をロールプレイ相手役に限定し、評価や進行管理は決定的なロジックで扱っている。
現在のサービスでは プロダクト開発（MVP） に相当します。
面接や書類では「実務でどう判断するか」が見えず、入社後のミスマッチや早期離職につながる。候補者側も、入社前に仕事の実態を体験する手段がなかった。
候補者が実際の業務場面を模した分岐シナリオを進み、選択に応じて複数のエンディングに到達するシミュレーションを構築した。結果は多軸のスコアリングでカルチャーフィットと能力フィットを可視化し、経歴書や推薦文の生成画面、採用担当者向けの管理画面まで揃えた。ターゲット層ごとにLPを複数作り分け、紹介動画とあわせて反応を検証した。
プロダクト本体だけでなく、ターゲット別LPと管理画面までを一人で作り切り、「誰に刺さるか」の検証を短いサイクルで回せる状態にした。市場調査からピッチ資料までを含む、事業立ち上げ型のプロダクト開発。
現在のサービスでは プロダクト開発（MVP） に相当します。
担当者が求職者に提案する求人や案件を探すため、複数の外部サイトに個別にログインして検索・確認していた。サイトごとに画面が違い、新着の見落としや同じ案件の重複確認が起きていた。ログインが必要でJavaScriptで描画されるサイトは、単純な取得では中身が読めない。
ブラウザ自動操作でログイン・検索・一覧取得を行い、収集した情報を1つの画面で分析できるツールを構築した。サイトごとの画面構造は設定ファイルに切り出し、構造が変わっても本体を触らず対応できる形にした。同じ考え方で、キーワード別に巡回して既知の案件を除外し、新着分だけを表形式で出力するクローラーも構築。ブラウザ自動化と判定・出力処理の役割分担を明確にし、PDF資料の一括取得にも同構成を転用した。
「取得できない前提」から逆算して、ブラウザ操作・判定・出力の3工程を分離した。各サイトの利用規約に従い、閲覧・記録のみを行う（自動応募は行わない）範囲に設計を限定している。
現在のサービスでは 生成AI 業務自動化 に相当します。
Free Diagnosis · 3 min
上記の事例に近い課題をお持ちなら、まずは7つの質問で自社のAI活用フェーズを確認してみませんか。市場データとの比較つきで結果がその場で分かります。
無料でAI活用度を診断する