ID:83311さん

■ プロジェクト概要 遺影画像の編集・加工および印刷用データ管理を効率化するデスクトップアプリの改修を担当。 既存コードを解析・把握したうえで機能改善を実施し、Windows向けexeとして納品まで完遂。 ※クライアントに許可を頂いて上で公開しております。 --- ■ 担当役割 ・既存コードの解析および全体の処理フローの把握 ・機能改善、UI調整からビルド、納品まで全工程を単独で担当 --- ■ 技術スタック 【バックエンド】 ・Pythonによる画像処理機能の最適化 ・CSV設定値を利用した画像配置ロジックの修正 ・FastAPIによるAPI処理の改善 【フロントエンド】 ・JavaScript / HTML / CSSによるUI調整 【ビルド・納品】 ・Windows環境向け実行ファイル（exe）としてアプリをビルドし納品 --- ■ 取り組んだ課題と工夫 ───────────────────────────── 【取り組み①】既存コードの解析と改修箇所の特定 ───────────────────────────── 【課題】 本案件は自身でゼロから設計するのではなく、他者が書いた既存コードへの改修対応であった。 コメントやドキュメントが不十分な状態で、画像処理・API・フロントエンドが絡み合う複数モジュールを 把握する必要があり、どこに手を入れると他の処理に影響が出るかが読みづらい状態だった。 闇雲に改修を始めると影響範囲の見落としや意図しないデグレードが発生するリスクがあると判断した。 【工夫】 ・まず改修に入る前に、コード全体を通読し処理フローを図として手元で整理するステップを設けた。 　データの入口（CSV・画像ファイル）から出口（印刷用データ出力）まで一連の流れを把握してから 　改修箇所を特定する進め方をとった。 ・FastAPIのエンドポイントとPython側の処理関数の対応関係を明確にしたうえで、 　変更による影響範囲を事前に確認してから手を入れる手順を徹底した。 ・クライアントとの仕様認識のずれが手戻りの主因になりやすいと考え、 　不明点はその都度確認・認識合わせを行い、要件のずれが生じないよう小まめにコミュニケーションをとった。 ・困難だった点：既存コードの設計意図が読み取りにくい箇所があり、 　動作確認しながら処理の意図を推測して読み解く必要があった。 　実際に入力データを変えながら挙動を確認するデバッグ作業を繰り返すことで処理ロジックを把握した。 【成果】 ・全体の処理フローを把握したうえで改修範囲を絞り込み、デグレードなく機能改善を完遂。 ・定性的に：仕様認識のすり合わせを小まめに行ったことで手戻りが発生せず、 　スムーズに納品・検収まで完遂できた。 ───────────────────────────── 【取り組み②】exe化・ビルド環境の構築 ───────────────────────────── 【課題】 クライアントへの納品形式がWindows向けの実行ファイル（exe）であり、 自身のPython開発環境で動作するコードを、クライアントのWindows環境でも 依存ライブラリなしに動作する形にパッケージングする必要があった。 画像処理ライブラリやFastAPIを含む複数の依存関係があり、 ビルド時に依存解決が失敗したり、ビルド後の実行時に特定モジュールが見つからないエラーが 発生するリスクがあると想定した。 【工夫】 ・PyInstallerを用いてexeビルドの環境を構築し、依存ライブラリが実行ファイルに 　同梱される設定を整備した。 ・ビルド後は自身のWindows環境で実際に動作確認を行い、 　モジュール欠落や実行時エラーがないことを検証してから納品する手順をとった。 ・困難だった点：画像処理系ライブラリがビルド時に自動検出されず、 　実行時に「モジュールが見つからない」エラーが発生するケースがあった。 　PyInstallerの--hidden-importオプションで明示的にモジュールを指定することで解消した。 【成果】 ・環境依存なく動作するexeファイルとして納品・検収完了。 ・定量的：成果報酬として1万円を受領し、エンジニアとして初の実務案件を完遂。 --- ■ 成果・現状 ・納品・検収完了。成果報酬として1万円を受領し、実務案件として完遂。 ・既存コード解析 / 画像処理最適化 / UI調整 / exe化まで一連の改修を単独で対応。 ・自走力と実務コミュニケーション能力をエンジニアとして初案件で実証。

■ プロジェクト概要 社内資料・PDFを知識源として、問い合わせ対応を自動化・効率化するRAG型AIエージェントを設計・開発。 解約・返金・請求などの定型問い合わせに対し、関連資料を検索したうえで根拠を明示した補助回答を提示する。 コール・チャット両チャネルに対応したマルチモード出力を実装し、実務での活用を想定した設計を採用。 --- ■ 担当役割 ・システム全体の設計 / アーキテクチャ設計 ・バックエンドからフロントエンド / インフラまで全工程を単独で担当 ・GitHub運用ルールの策定（チーム開発を想定した運用設計） --- ■ 技術スタック 【AI / 検索】 ・LangChain（OpenAI API連携 / プロンプト管理 / エージェント構築） ・OpenAI API（GPT-4o-mini：回答生成 / text-embedding-3-small：ベクトル化） ・ChromaDB（ベクトルDBとして検索インデックスを永続化） ・BM25 + ベクトル検索によるハイブリッド検索（RRF：相互順位融合で精度向上） ・クエリリライト（LLMによる検索クエリの最適化） ・自己改善ループ（エージェントによる回答の自己レビュー・修正） 【バックエンド】 ・Python 3.11 ・pypdfによるPDFロード・テキスト抽出 ・カテゴリ推定 / クエリ前処理モジュールの実装 【フロントエンド】 ・Streamlitによる画面構築 ・コールモード（トークスクリプト自動生成） ・チャットモード（返信文自動生成・ワンクリックコピー） ・ログCSVエクスポート機能（質問 / 回答 / 自己評価スコア / 引用元の履歴管理） 【インフラ】 ・Docker / Docker Composeによるコンテナ環境の構築 --- ■ 取り組んだ課題と工夫 ───────────────────────────── 【取り組み①】検索精度の向上（ハイブリッド検索の設計） ───────────────────────────── 【課題】 社内PDFを対象とした検索において、単語の完全一致を前提とするキーワード検索（BM25）だけでは、 表現の揺れや意味的な近さを考慮した検索が困難であった。 一方、ベクトル検索単体では、固有名詞や専門用語など具体的なキーワードへの反応が弱く、 どちらか一方だけでは業務で使えるレベルの精度を確保できないと判断した。 【工夫】 ・BM25（単語一致）とベクトル検索（意味一致）を組み合わせたハイブリッド検索を採用。 ・2つの検索結果を統合するスコアリング手法として RRF（相互順位融合）を選定。 　RRFは各手法のスコアを順位ベースで統合するため、スコールスケールの違いを吸収でき、 　シンプルかつ安定したマージが可能な点を評価した。 ・「単語としての一致」と「意味的な近さ」の両面をカバーすることで、 　単一手法では取りこぼしていたチャンクを補完的に拾える設計とした。 ・困難だった点：2手法のスコアをどう統合するかの設計判断が難しく、 　加重平均・正規化・RRFなど複数のアプローチを比較検討した上で RRF を採用した。 【成果】 ・単一手法と比較して、表現の揺れがある質問でも意図した資料チャンクをより上位に取得できるようになった。 ・定性的に：「解約したい」「契約を終わらせたい」など同義の異表現でも同一資料が検索されることを確認。 ───────────────────────────── 【取り組み②】回答品質の担保（自己改善ループの実装） ───────────────────────────── 【課題】 RAGシステムでは、検索で取得したチャンクが不完全な場合、そのまま誤った・不十分な回答が オペレーターに提示されてしまうリスクがある。 人手でのレビューをシステムに組み込むことは運用コストが高いため、 AIエージェント自身が回答の品質を評価・修正できる仕組みが必要と考えた。 【工夫】 ・エージェントが初回回答を生成した後、自己レビュープロセスを挟む2段階パイプラインを設計。 ・自己レビューでは「正確性」「網羅性」の2軸で回答をスコアリングし、 　閾値を下回った場合は再検索・回答修正を自動で実行する自己改善ループを実装。 ・スコアはログとしてCSVに記録し、回答精度のトレース・振り返りができる設計とした。 ・困難だった点：自己評価プロンプトの設計が難しく、 　スコアが甘すぎる・辛すぎるなどのバイアスが出やすかったため、 　評価軸の定義と出力フォーマットを細かく調整する試行錯誤が必要だった。 【成果】 ・自己改善ループにより、初回回答が不十分な場合でも再検索・補完が自動で走る設計を実現。 ・定性的に：スコアが低い回答で「追加質問」や「記載なし」を返すフォールバックが機能し、 　誤情報の提示を防ぐ安全設計として機能することを確認。 --- ■ 成果・現状 ・コール / チャット両対応のRAG型AIエージェントとしてポートフォリオ公開済み。 ・ハイブリッド検索 / 自己改善ループ / マルチモード出力など、 　実務運用を意識した機能を単独で設計・実装。 ・今後はCloud Runへのデプロイ / 多言語対応 / 音声通話対応を予定。

■ プロジェクト概要 チャット・コールセンター業務において練習機会が不足しがちという現場課題に着目し、 AIを活用したロールプレイ型トレーニングツール「RoleUp」を設計・開発。 難易度3段階（初級 / 中級 / 上級）と実務頻出シナリオ（解約引き止め / 請求トラブル / クレーム対応）を実装し、 トレーナー不在でもいつでも反復練習できる自己学習型の設計を採用。 --- ■ 担当役割 ・システム全体の設計 / アーキテクチャ設計 ・バックエンドからフロントエンド / インフラまで全工程を単独で担当 ・難易度別の顧客態度設計に現場経験を反映 ・GitHub運用ルールの策定（チーム開発を想定した運用設計） --- ■ 技術スタック 【AI / 検索】 ・LangChain（会話管理 / フィードバック生成 / プロンプト管理） ・OpenAI API（GPT-4o-mini：顧客役AI / フィードバック生成） ・FAISS（ベクトルDB / RAG検索） ・PyMuPDF（PDFナレッジ読み込み） ・RAG構成によるPDFナレッジ参照機能の実装 【バックエンド】 ・Python 3.11 ・エージェントによる応答生成 / フィードバック生成ロジックの実装 ・プロンプト管理モジュールの設計（ロールプレイ用 / フィードバック用を分離） 【フロントエンド】 ・Chainlitによるチャット形式UIの構築 ・難易度選択 / シナリオ選択 / 対応終了トリガーの実装 【インフラ】 ・Docker / Docker Composeによるコンテナ環境の構築 --- ■ 取り組んだ課題と工夫 ───────────────────────────── 【取り組み①】リアリティある顧客態度の設計（難易度別プロンプト設計） ───────────────────────────── 【課題】 ロールプレイ型のトレーニングツールでは、AIが演じる顧客キャラクターのリアリティが 練習効果に直結する。難易度に関係なく同じような顧客態度では、 新人向けの易しい練習と経験者向けの応用練習を分けることができず、 「誰でも使えるが誰にも刺さらない」ツールになるリスクがあると判断した。 また、AIに顧客役を演じさせる際、指示が曖昧だと感情表現がぶれたり、 シナリオから逸脱した応答が生成されるという技術的な課題もあった。 【工夫】 ・コールセンター現場での実務経験をもとに、難易度ごとの顧客キャラクターを言語化・設計。 　初級は「穏やかで話を聞いてくれる顧客」、中級は「不満はあるが対話できる顧客」、 　上級は「感情的で攻撃的なクレーム顧客」と明確に定義した。 ・各キャラクターをプロンプトに落とし込む際、口調・感情の強度・反論パターンを具体的に記述し、 　AIの応答がシナリオ設定から逸脱しないよう制御する設計とした。 ・ロールプレイ用プロンプトとフィードバック用プロンプトをモジュールとして分離し、 　顧客役AIと評価AIが干渉しない構成にした。 ・困難だった点：プロンプトだけで感情の「強度」を安定的に制御するのが難しく、 　上級シナリオで顧客が過度に攻撃的になりすぎたり、逆に設定より穏やかになるケースが発生した。 　ペルソナ定義の粒度を細かくし、NG応答パターンを明示的に除外する記述を追加することで安定させた。 【成果】 ・難易度ごとに異なる顧客態度が再現でき、新人から経験者まで段階的に活用できる構成を実現。 ・定性的に：上級シナリオでは実際のクレーム対応に近い緊張感のある練習体験が生成されることを確認。 ───────────────────────────── 【取り組み②】フィードバック品質の担保（評価プロンプトの独立設計） ───────────────────────────── 【課題】 トレーニングツールとして機能するためには、練習後のフィードバックの質が重要になる。 顧客役AIと同一のプロンプト・会話コンテキストでフィードバックを生成しようとすると、 「顧客視点」と「評価者視点」が混在し、具体的で客観的な改善指摘が出にくいという問題があった。 また、「もっと丁寧に話しましょう」といった抽象的な指摘では学習効果が薄く、 実際の対応改善につながらないフィードバックになるリスクがあった。 【工夫】 ・顧客役AIとフィードバック生成AIを役割レベルで分離し、それぞれ独立したプロンプトを設計。 ・フィードバックプロンプトでは「会話全体を振り返り、具体的な発言を引用しながら改善点を指摘する」 　よう指示を与え、抽象的な評価ではなく発言ベースの具体的なフィードバックが生成されるよう設計。 ・評価軸として「共感表現の有無」「解決策の提示」「クロージングの適切さ」などを明示的に定義し、 　フィードバックの一貫性を担保した。 ・困難だった点：会話履歴全体をフィードバック生成の入力に含める設計にしたため、 　会話が長くなるにつれコンテキスト長が増大し、応答精度の低下やレイテンシ増加が課題となった。 　会話の要約ステップを挟むことで、長い会話でも安定したフィードバック生成ができる構成に改善した。 【成果】 ・対応終了後に会話全体を分析した具体的なフィードバックが自動生成される設計を実現。 ・定性的に：「〇〇の発言時に共感表現が不足していた」といった発言レベルの指摘が生成されることを確認し、 　抽象的なフィードバックに留まらない設計として機能していることを確認。 --- ■ 成果・現状 ・難易度3段階 / 実務頻出シナリオを備えたロールプレイ型AIトレーニングツールとしてポートフォリオ公開済み。 ・チャットUI / RAG検索 / フィードバック生成を統合した一気通貫の学習体験を単独で設計・実装。 ・今後は業種別シナリオの追加 / スコア履歴表示 / 育成担当者向け管理画面の実装を予定。

HTML / CSS / JavaScript（Vanilla ES6+）のみを使用し、フレームワークに頼らずシングルページのポートフォリオサイトを設計・実装。 GitHubのコードだけでは伝わりにくい「人となり」や「エンジニアを目指した背景」を伝えるために制作。 略歴・職務経歴・開発経験・スキルセットに加え、趣味の切り絵ギャラリーまで掲載し、 採用担当者やクライアントへの「名刺」として機能するサイトを目指した。 ───────────────────────────── 【取り組み①】PC・スマートフォン両対応のレスポンシブレイアウト設計 ───────────────────────────── 【課題】 ポートフォリオサイトは採用担当者・クライアントが閲覧するため、 PCだけでなくスマートフォンからのアクセスでも崩れなく表示される必要があった。 フレームワークを使わずHTML / CSS / JavaScriptのみで構築したため、 BootstrapなどのUIライブラリが提供するレスポンシブグリッドを使えず、 レイアウト崩れへの対処をすべて自前で設計しなければならない状況だった。 【工夫】 ・メディアクエリを用いてPC / タブレット / スマートフォンの3段階でレイアウトを切り替える設計を採用。 　ブレークポイントごとにナビゲーション・ギャラリー・スキルバーなど 　崩れやすい要素を個別に検証しながらスタイルを調整した。 ・CSSカスタムプロパティ（変数）でフォントサイズ・余白・カラーを一元管理し、 　デバイスごとに値を切り替えるだけで全体のスタイルが統一されるよう設計した。 　これにより、修正箇所が1箇所で済み、デバイス間の表示一貫性を保ちやすくした。 ・困難だった点：切り絵ギャラリーやスキルバーなど、 　要素の数や幅が可変になるセクションでスマートフォン表示時にはみ出しや 　縦並び崩れが発生しやすく、FlexboxとGridの使い分けを試行錯誤しながら安定させた。 【成果】 ・PC・スマートフォン・タブレットの全デバイスでレイアウト崩れなく表示されることを確認。 ・定性的に：フレームワーク不使用でレスポンシブ対応を自前で実装したことで、 　CSSレイアウトの基礎（Flexbox / Grid / メディアクエリ）を実践的に習得できた。 ───────────────────────────── 【取り組み②】情報設計・UXを意識したページ構成の整理 ───────────────────────────── 【課題】 略歴・職務経歴・スキルセット・開発実績・趣味（切り絵）と掲載情報が多岐にわたるため、 そのまま並べると情報過多になり、読み手が途中で離脱するリスクがあった。 「採用担当者やクライアントが最初に何を知りたいか」を起点に、 掲載順・ボリューム・見せ方を設計する必要があると判断した。 【工夫】 ・読み手の視点に立ち、「第一印象 → 経歴・スキル → 実績 → 人となり」という 　情報の流れを意識してセクション順を設計した。 ・情報密度が高いセクション（職務経歴・スキルセット）は余白・フォントサイズ・ 　アコーディオン構造を活用してスキャンしやすいレイアウトに調整した。 ・趣味の切り絵ギャラリーをあえて最後のセクションに配置することで、 　技術・経歴だけでは伝わりにくい人となりを補足し、記憶に残る印象を意図した。 ・IntersectionObserver APIによるスクロール連動アニメーションを実装し、 　単調になりがちなシングルページ構成に動きを加えて閲覧体験を高めた。 ・困難だった点：情報の取捨選択と掲載順の判断に正解がなく、 　実際にスマートフォンで通して読みながら「どこで読む気が失せるか」を自分で検証し、 　ボリュームや順番を何度も見直した。 【成果】 ・自己紹介からスキル・実績・人となりまで一貫して伝わるシングルページサイトとして完成。 ・Cloudflare Workersでデプロイし、URLで即座に共有できる状態で公開済み。 ・定性的に：コードだけでは伝わらない思考プロセスや個性を可視化できる 　「エンジニアとしての名刺」として機能するサイトを自力で完成させた。 ▼自己紹介ウェブサイトURL▼ https://long-firefly-b5db.biguver.workers.dev/