各実績を「困っていたこと → 作ったもの → どうなったか」の順で書いています。末尾に担当したフェーズと使った技術を小さく添えました。
守秘義務のため、お客様の名前・屋号・地域・金額は伏せています。業種の大分類までの記載です。
困っていたこと：規程・マニュアル・過去の照会記録が社内に分散していて、担当者が都度探して回答している状態でした。一般的なAIをそのまま使っても社内固有の内容には答えられず、事実に基づかない回答（ハルシネーション）が業務上のリスクになります。
作ったもの：社内文書を読み込ませておき、根拠の文書を参照したうえで答えるRAG（社内文書をAIに読ませて答えさせる仕組み）を構築しました。回答には必ず出典（どの文書のどこを見たか）を添えます。質問の意図を分類してから検索する形にし、業務の流れに沿って答えられるようにしました。個人情報の検知とマスキング、APIキーを利用者に見せない構成もあわせて設計しています。
どうなったか：文書の分け方・検索件数・再ランキング（検索結果の並べ直し）を変えながら、想定質問への正答率と参照の適合率で比較して構成を決めました。根拠を自分で確認できる形で回答が返るようになっています。
困っていたこと：必要な情報がPDFの中に埋もれていて、問い合わせのたびに人が探して答えていました。
作ったもの：PDFの取り込み・分割・意味の数値化（埋め込み）・検索・回答生成までを一本につないだRAGを構築しました。顧客折衝から技術選定、要件定義書・基本設計書・詳細設計書の作成、テスト仕様書に沿った検証まで、一人で担当しています。
どうなったか：PDFに埋もれていた情報を、問い合わせに応じて根拠付きで返せる形にして納品しました。
困っていたこと：PDFの中から決まった項目を人が目で探して転記する作業が続いていました。書式が一定でないため、単純な自動化が効きません。
作ったもの：PDFの取り込みから、必要な情報の抽出、出力までの処理を設計・実装しました。3名体制の案件で、要件定義書・基本設計書・詳細設計書を整備しながら進めています。
どうなったか：手作業での情報探索と転記の負担を減らす仕組みとして構築を進めています。抽出の精度と、書式が変わったときの扱いを詰めながら、現在も開発を継続中です。
※ 社内向けの問い合わせ応答システム（自社向けRAG）については、「9.『何ができるか分からない』から、相談できる」の生成AI活用セミナーの項をご覧ください。
困っていたこと：領収書が紙とメールに散らばり、集める・読み取る・記帳するのがすべて手作業でした。電子で受け取った領収書は電子帳簿保存法への対応も必要になります。
作ったもの：スマホで撮った領収書を法令に適合する形で保存し、日付・金額・取引先・登録番号をOCR（画像から文字を読み取る技術）で取り出すアプリです。メールに届いた電子領収書をアプリ側が探して集める機能、PDF領収書の取り込み、機種変更時のデータ復元まで実装しています。読み取りエンジンは複数から差し替えられるよう抽象化し、APIキーを利用者に露出させず利用者ごとに上限を設ける方式にしました。
どうなったか：撮影・収集から保存・記帳の下書きまでを一つのアプリで扱える形になり、外部の会計ソフトへ渡す連携も含めて開発を継続しています。
困っていたこと：複数の販売・予約システムに売上が分かれていて、日別・月別の合計や客単価を毎回手で集計していました。特に客単価の計算が属人化していました。
作ったもの：分散した売上データを自動で集めて統合し、日別・月別の売上と客単価を自動算出する画面を作りました。複数店舗の切り替えにも対応しています。さらに、過去の実績から来客数を予測する機能（LightGBMという機械学習の手法）を追加し、予測がどれくらい当たるかも画面に表示しています。
どうなったか：手作業だった集計が自動になり、夜間に自動で学習し直す形で本番運用しています。データベースの移行（SQLite → PostgreSQL）も実施しました。
困っていたこと：営業のアプローチ先リストの作り方が粗く、リストの再活用もできていませんでした。どの企業が見込みありなのかが、担当者の感覚に頼っていました。
作ったもの：営業リストを自動作成するツールと、企業の特徴と営業結果を突き合わせて相性を点数化するツールをPythonで作りました。表計算での点数管理の仕組み化もあわせて行っています。
どうなったか：チームのリーダーとして全体のアポイント獲得数130%を達成し、個人では月100件のアポイント獲得を実現しました。
困っていたこと：注文がメッセージのやり取りでの手作業に頼っていて、決済・会員管理・売上把握までが分断されていました。季節で商品が入れ替わるため、非エンジニアのご本人がスマホから運用できることも条件でした。
作ったもの：ECサイト構築用のオープンソース（EC-CUBE）をベースに、要件の整理から比較検討・構築・公開・保守まで担当しました。クレジットカード・コード決済、会員登録とマイページ、売上管理ダッシュボード、スマホ用の管理画面、商品をワンタップで表示／非表示できる季節商品の運用、アクセス解析タグとSEO用メタ情報の自前実装などを実装しています。補助金申請に必要な資料整理の支援も行いました。
どうなったか：手動での注文受付から、決済・会員・売上管理まで備えた自社のネットショップへ移行しました。有料プラグインを買わずに自前実装する判断で、初期費用と保守対象を抑えています。
困っていたこと：注文データ、サイトのアクセス状況、検索されたキーワードが、それぞれ別のサービスにあり、突き合わせて見ることができませんでした。
作ったもの：ネットショップの注文データ、アクセス解析、検索キーワードのデータを、それぞれの公開APIから自動で取得して1か所に集める仕組みを作りました。取得と集計はサーバーレス（常時起動のサーバーを持たない構成）で動かし、認証はOAuth、アクセストークンは暗号化して保管しています。集計結果はグラフ付きの画面で確認できます。
どうなったか：売れ行きの変化を、アクセス数や検索キーワードと並べて確認できるようになりました。
困っていたこと：出欠、保護者への連絡、月謝の集金、顧客管理が、それぞれ別のサービスに分かれていました。教室ごとに事情が違うため、1つの仕組みを複数の教室で安全に共有できることも必要でした。
作ったもの：出欠 → 保護者への自動通知 → 月謝集金 という流れを軸に、欠席連絡、予定変更の申請、掲示板、保護者と運営の1対1トークまでを1つにまとめたマルチテナント型（1つのシステムを複数の教室が使う形）のサービスです。教室ごとのデータは、データベース側の行単位のアクセス制御で完全に分離しています。運営者／オーナー／講師／保護者／生徒それぞれの権限を設計し、通知の届け方と支払い方法は差し替えられる形にしました。
どうなったか：分散していた機能を1システムに統合し、複数の教室へ提供できる設計になりました。インフラはコード化（Terraform）して、日次バックアップの自動化とコストの最適化を行っています。
困っていたこと：個人事業主や小規模事業者の集客は、ページ作成・メール配信・LINE・決済・会員サイトがバラバラで、運用に人手がかかります。ツールを使いこなす時間も人手もない、という状態が起こりがちです。
作ったもの：集客の入口から購入・フォローまでを1つの導線にまとめる基盤です。特徴は3つあります。（1）お客様の行動記録をAIが読み、「誰に・いつ・何を送るか」を複数案と理由つきで提案し、承認したら実行する。決めるのはご本人です。（2）配信やページ公開の前に、薬機法・景表法・特商法・特定電子メール法の観点で表現をAIが点検して警告する。（3）AIに人格を委ねず、ご本人の過去の言葉を参照して書き、手を入れた差分を学習材料に戻す。
どうなったか：自社プロダクトとして開発中です。個人情報・配信・決済を扱うため、承認なしでの実行を禁じる仕組みを土台側に1つだけ置く設計にしています。
困っていたこと：「似ているものを見分ける」ためのAI手法が数多く発表されていて、自社のデータと課題に合うものがどれか判断できない状態でした。
作ったもの：対照学習（似ているもの同士を近づけ、違うもの同士を遠ざけるようにAIに学習させる手法）に関する論文を約100本調査し、要約して提案資料にまとめました。そのうえで、選んだ手法をお客様のデータセットと既存モデルに組み込み、複数手法の組み合わせ・学習・評価まで担当しました。
どうなったか：当初は単独手法の検討でしたが、ご要望を汲んで組み合わせを提案し、精度が出ない課題に対して手法の変更でアプローチしたことを評価いただきました。
困っていたこと：「将来的に使えそうな画像生成の技術を知っておきたい」というご要望がありましたが、社内に判断材料がありませんでした。
作ったもの：画風変換・生成AIに関する論文を約100本調査し、提案資料にまとめました。お客様が選んだ10本については、1本あたりスライド約40枚規模で詳細に解説しています。そのうち1本は実際に実装して動かすところまで担当しました。
どうなったか：事前に事業内容と保有データを伺ったうえで親和性の高い論文を選んで調査したため、内容の質についても評価をいただきました。
困っていたこと：空調の制御をAIに学習させたいものの、クラウド上に学習・評価を再現性のある形で回せる環境がありませんでした。
作ったもの：AWS上にネットワークから学習環境までを構築し、強化学習（試行錯誤しながら良い操作を学ばせる手法）で空調制御のエージェントを学習・評価しました。
どうなったか：クラウド上で制御エージェントを学習・評価できる基盤が整い、制御の最適化に向けた検証を進められる状態になりました。
困っていたこと：画像生成AIが動画にどこまで使えるのか、実際に手を動かして確かめておきたいと考えました。
作ったもの：映像を1コマずつ画像に分解し、画像生成AI（img2img とLoRA という追加学習の仕組み）で指定した画風に変換して動画に戻す一連の処理を作りました。効果音の合成、コマ数の間引きによる生成コストの調整、変換の強さの調整も含めて検証しています。
どうなったか：短い映像であれば、画風を保ったまま変換できることを確認しました。生成にかかる費用と品質のトレードオフも、手元の数字で把握できています。
困っていたこと：ロボットを動かすには、人が個別の制御コマンドを組み立てる必要がありました。また、走行中に引っかかって（スタックして）止まると、人が気づいて対処するまで動けませんでした。
作ったもの：自然言語で指示すると、AIが自分でタスクを分解し、使う機能を選んで実行する制御の仕組みを作りました。命令の解釈・行動計画・状態認識・実行監視をそれぞれ別のAIエージェントに分け、片方が失敗しても全体が止まらない構成にしています。距離センサーと画像認識AIでスタック・障害物・ゴール到達を判断し、引っかかったら「後退 → やり直し → 経路の引き直し」と段階的に自分で立て直します。
どうなったか：指示が失敗しても人が介入せずに次の手を打てるようになり、連続動作の成功率が改善しました。実行環境をまるごとコンテナ化し、実機がなくてもブラウザから同じデモを再現できる状態にしています。
困っていたこと：安全運転のフィードバックが「速度を落としましょう」といった画一的な内容にとどまり、運転の改善につながりにくい状態でした。
作ったもの：「どの道が危ないか」と「その人の運転の癖」の両面からリスクを捉える分析を設計しました。過去の事故データと地図データ（OpenStreetMap）を突き合わせ、道路の種類・交差点までの距離・信号の有無から道路ごとの危険度を推定。あわせてGPSの走行記録を最寄りの道路に対応づけ、発進・加速・減速・旋回といった場面ごとの特徴を距離あたりに直して抽出しました。正解ラベルがないため、教師なしの手法で運転スタイルを類型化し、移動の目的の推定と組み合わせています。
どうなったか：画一的だったフィードバックを「道路のリスク × 運転の癖 × 比較」の3軸で個別化する設計にまとめました。中間報告の段階で、データ規模の限界や取得できない項目も率直に共有しています。
困っていたこと：自動運転で使われる技術の中から、自社の方針に合うものを選びたいが、判断材料がそろっていない状態でした。
作ったもの：自動運転における点群SLAM（レーザーで測った点の集まりから、自分の位置と周りの地図を同時に作る技術）の深層学習系アルゴリズムについて論文を約60本調査し、ご要望に沿ったものを抜粋・取りまとめて提案しました。
どうなったか：ご評価をいただき、調査内容をシミュレーターに反映するところまで追加でご依頼をいただきました。
困っていたこと：「生成AIが便利らしい」と聞いていても、自社のどの業務で使えるかが分からない、というご相談が多くありました。
作ったもの：外部向けの生成AI活用セミナーでファシリテーターを務めました。セミナー講師と連携し、参加企業のご要望を伺いながら次回のトピックを決める形で進めています。あわせて、プロンプトの最新手法・RAG・生成AIアプリ開発・他社サービスの調査を継続し、自社向けの社内文書AI（RAG）も構築しました。
どうなったか：「何に使えるか」を一緒に考える場として運営し、調査内容をそのまま自社の実装にも反映しました。
困っていたこと：社内にクラウド（Azure）と大規模言語モデルの知見がなく、AIを使ったデモを出せない状態でした。
作ったもの：社内チャットツール（Slack）と生成AIを連携させたWebアプリを、Azure上で稼働させました。クラウド環境の調査、モデルの用意、チャットツールのAPI調査、両者の連携までを担当しています。
どうなったか：調査の進め方を評価いただき、そのプロジェクトの技術検証（PoC）をすべて任せていただくことになりました。
困っていたこと：社内で感謝を伝え合う文化を根づかせたいものの、そのための仕組みがありませんでした。
作ったもの：社内チャットで相手にメンションするとポイントが付与されるアプリを作りました。日次でのポイントのリセット、やり取りの履歴管理、ワークスペースの認証管理を含みます。常時起動のサーバーを持たないサーバーレス構成です。
どうなったか：納品後も機能追加・バグ修正・お問い合わせ対応・障害対応を継続して担当しました。
困っていたこと：ボランティアの申込みが集まったあと、日程ごとの参加者一覧を作り、連絡先を突き合わせ、確定したシフト表に清書する作業が、すべて手作業で発生していました。
作ったもの：申込フォームの回答から、日程別の参加者一覧を自動生成し、連絡先を自動で結合、確定のチェックを入れると確定シフト表ができあがる仕組みを、フォームと表計算だけで作りました。同時編集で壊れないようロックを取り、参加者には管理用のIDを振っています。
どうなったか：新しくシステムを作らずに、無料で使える範囲だけで運用できる形になりました。費用をかけずに済むなら、そう提案します、という一例です。
| 項目 | 実績 |
|---|---|
| 論文調査 | 累計約260本（点群SLAM 約60本／対照学習 約100本／画風変換・生成AI 約100本、ほかドライバ行動分析を7分類でサーベイ） |
| 詳細解説資料 | 論文1本あたりスライド約40枚規模 |
| 個人開発プロダクト | 3件を企画から本番運用まで単独で担当 |
| 営業支援ツール時代 | チームのアポイント獲得数130%達成／個人最大 月100アポイント |