技術

通算経験年数

案件期間を月単位でユニオン（重複月を除外）して集計しています。2026年8月時点。

同じ技術を複数案件で使っているため、案件期間の単純合計ではなく「実際にその技術に触れていた期間」で算出しています。案件ごとの期間表記と矛盾しません。

案件の呼び方（以下の記述で使う略称）

守秘義務のため、顧客名・製品名は伏せて抽象化した呼び方を使います。

言語

AI / LLM

この領域が主戦場です。 フリーランス媒体のスキル欄には選択肢が用意されていないことが多く、表現しきれていない部分をここに書きます。

RAG（検索拡張生成）— 約2年

RAGを「作ったことがある」ではなく、精度を数値で比較して構成を決めるところまでやっています。

• パイプライン全体の設計・実装：ドキュメント取り込み → チャンク分割 → 埋め込み生成 → ベクトル検索 → 再ランキング → 回答生成（金融RAG／PDF-RAG／セミナー・自社RAG）
• 出典付き回答：回答に参照文書と該当箇所を必ず併記し、利用者が根拠を確認できる形にする（金融RAG）
• 検索精度の改善：チャンクサイズ・分割方針・検索件数・再ランキングの有無を振って比較評価（金融RAG）
• ハイブリッド検索：ベクトル検索とキーワード検索の併用による、表記ゆれ・専門用語への対応（金融RAG）
• 非構造データからの情報抽出：PDFの取り込みと、必要項目の構造化抽出（PDF-RAG／PDF抽出）
• RAGの上位設計：単発のQAに閉じず、意図分類 → 必要な検索の実行 → 回答生成というステップに分解（金融RAG）

LLM評価設計

「なんとなく良くなった」で終わらせないための評価を、案件の中で組んでいます。

• 想定質問セットを用意し、正答率・参照適合率で構成候補を定量比較（金融RAG）
• 実験条件と結果をドキュメント化し、非エンジニアの関係者にも読める形で報告（金融RAG）
• 対照学習・画風変換では、複数手法の組み合わせを学習・評価して比較（対照学習／画風変換）
• 需要予測では、交差検証の平均を基準にハイパーパラメータを選び、予測精度をUI上に明示（売上ダッシュボード）
• LLMの判定ロジックを純粋関数として分離し、テスト可能な形にする（財務AIアプリ）

AIエージェント開発 — 約1年6ヶ月

• 自律制御ループ：自然言語命令の解釈 → タスク計画 → 使用ツール／ノードの選択 → 実行 → 結果評価（ロボット制御）
• マルチエージェント：命令解釈・行動計画・状態認識・実行監視を独立したエージェント／ノードに分離し、メッセージ経由で協調。片方の失敗が全体を止めず、個別に差し替えられる責務分割（ロボット制御）
• 自律リカバリ：スタック検知時に「後退 → 再試行 → 経路再生成」と段階的に復帰を試みる制御（ロボット制御）
• 業務特化エージェント：意図分類から検索実行までを業務フローに沿って組む（金融RAG）
• 意思決定エージェント：行動ログを読み「誰に・いつ・何を送るか」を複数案＋根拠つきで提案し、承認を経て実行する設計。承認なしの実行を禁じる安全ゲートをドメイン層に1つだけ置く（マーケ基盤）
• MCP サーバ：外部のLLMクライアントから接続させる入口を用意しつつ、公開・送信の実行権限は渡さない設計（マーケ基盤・開発中）

LangChain

• RAGパイプライン（ローダ／スプリッタ／リトリーバ／チェーン）の実装に使用（金融RAG）
• 実装が固まった箇所は、依存を減らすためLLM APIの直接呼び出しへ寄せる判断も行っています

生成AI / LLM API

• Anthropic / OpenAI / Google / Azure OpenAI を用途とコストで使い分け（金融RAG／PDF-RAG／PDF抽出／財務AIアプリ／マーケ基盤／学習管理システム）
• プロンプトエンジニアリング：最新手法の論文調査を行い、セミナー教材と自社実装の両方に反映（セミナー／自社RAG）
• 構造化出力：OCR結果を日付・金額・取引先・登録番号のスキーマに落とす（財務AIアプリ）
• VLM（画像認識LLM）：カメラ画像からのスタック検知・障害物検知・ゴール到達判定（ロボット制御）
• 小テストの自動生成：既存の教材範囲に連動した出題（学習管理システム）
• 画像生成：img2img とLoRAによる画風変換を映像フレームに適用（動画生成検証）

安全側の設計（正確さが要る領域向け）

• PII検知・マスキング：入力に含まれる個人情報・機微情報を検知してマスクするガードレール（金融RAG）
• LLMプロキシ：APIキーを利用者に露出させず、プロキシ経由で利用ログと利用者ごとのレート制限を管理（金融RAG／財務AIアプリ）
• プロバイダ抽象化：OCR／LLMのプロバイダを設定で切り替え可能に（端末OCR／クラウドLLM各社）（財務AIアプリ）
• 法令コンプライアンスの自動チェック：配信・公開の前に薬機法・景表法・特商法・特電法の観点で表現をスキャンして警告（マーケ基盤）
• 顧客の個人情報をLLMに渡さない方針の切り分け（売上ダッシュボード）

機械学習・深層学習

ロボティクス

進め方の面では、実機依存を避けてシミュレーションに限定し、まずルールベースの最小実装を完成させてからAI機能を載せる順序にすることで、スコープ肥大化とデモの不安定化を防ぎました。

地理情報 / GIS

フロントエンド

バックエンド

FastAPI

• RAG／LLMアプリのバックエンドAPIをPythonで構築する際に使用（金融RAG／PDF-RAG）
• LLMプロキシ（APIキー秘匿・利用者ごとレート制限・利用ログ）のエンドポイント実装
• Pydanticによるリクエスト／レスポンスのスキーマ定義と、LLM構造化出力の型付け

その他

データベース

課金・出欠・売上など数え間違えられない値を扱う箇所では、集計の定義（対象ステータス・期間の判定基準）を1か所に集約し、別画面と数字がズレない形にしています（EC構築では本体ダッシュボードと完全に同一の定義に合わせました）。

インフラ / DevOps

Terraform（IaC）

• スクールSaaSのAWSインフラをコード化。Amplifyホスティング、SESのドメイン認証・本番アクセス申請を含む構成を再現可能な形で管理
• 手作業のコンソール操作を残さないことで、環境の作り直し・引き継ぎができる状態を維持
• 無料枠を前提としたコスト最適化と、日次バックアップの自前自動化をあわせて実装

その他

統計

• 統計検定の学習を通じて、t検定・仮説検定など、データ分析・機械学習で用いる大学学部レベルの統計学を学んでいます
• 実務では、交差検証の平均を基準としたモデル選択、正則化による過学習の抑制、運転シーン別の分布による妥当性検証などに活用しています

開発の進め方・強み

• AIとプロダクトの両方を接続できる — RAG・エージェント・機械学習モデルを作るだけでなく、それを使えるアプリケーションとインフラまで自分で組み立てて届けられます。
• 調べて選べる — 論文調査を起点に手法を選定し、顧客の事業内容・保有データとの親和性まで踏まえて提案 → 実装 → 評価まで通します。
• 教師データが無い前提から始められる — 正解ラベルが存在しない実データに対し、教師なし手法・ルールベースの第一版・論文サーベイを組み合わせて、まず使える形を作ります。
• 0→1の立ち上げに強い — 曖昧な要件を対話で具体化し、要件定義書・データモデル・仕様書・デプロイ手順書を整備しながら、動く本番システムまで一人で到達させます。
• 正確さが要る領域への配慮 — 金融（個人情報・機微情報）、会計・税務（法令準拠）、認証・認可、課金、データ整合性など、間違えられない領域を切り分けて慎重に設計・実装します。
• 限界を含めて報告する — データ規模の制約、取得できなかった項目、精度の妥当性を隠さず共有し、関係者が判断できる状態にすることを重視しています。
• コスト意識 — 無料枠・サーバーレス・IaC・キャッシュ設計を活用し、小さく始めて段階的にスケールできる構成を選びます。有料プラグインを買わずに自前実装する、といった判断も含みます。
• 小さく縦に切る — 大きな機能は「1フロー分の動くもの」から作ります。最小実装を先に完成させてからAI機能を載せる、という順序を守ります。

担当できるフェーズ

要件ヒアリング／要件定義書・基本設計書・詳細設計書の作成／技術選定／実装／テスト仕様書の作成・テスト実施／インフラ構築・本番デプロイ／運用・保守・障害対応／顧客への報告・技術発信

営業職の経験があるため、非エンジニアの関係者に向けた説明資料の作成と報告を得意としています。5名前後のチームマネジメント経験もあります。