FDE向けGitHubポートフォリオ｜起動・評価・制約を伝えるREADME構成

2026 10/25

2026年10月19日 2026年10月25日

著者: Walkers編集部公開: 2026年10月19日最終更新: 2026年10月25日

Forward Deployed Engineer（FDE）を目指すエンジニアが個人制作のリポジトリを公開する際、コード本体に加えてREADMEの記述が読者の理解を助けます。重要となるのは、画面の見た目だけでなく、第三者が手元で起動できる手順、出力精度の評価方法、運用時に生じる既知の制約、そして自身の担当範囲を明記することです。なお、ここで紹介するREADMEの項目や構成は、情報整理の手順として編集部が提案する雛形であり、特定の企業が指定した応募形式ではありません。また、この形式に沿って記述することで選考結果や伝達効果を保証するものではありません。

READMEを通じて課題選定から運用・限界の理解へ至る説明の順序

1. 課題と範囲想定利用者と対象作業を絞り、自動化しない領域を明示する。
2. 選定理由採択理由と未実施の比較計画を区別して記す。
3. 動く実装前提環境と起動手順を整え、第三者が手元で再現可能にする。
4. 評価方針該当なしケースを含む評価セットを作り、実測枠を設ける。
5. 運用と限界データ更新手順や未対応の制約を机上想定と分けて説明する。

デモに添える課題の定義と選定の比較計画

成果物としてリポジトリを公開するとき、起動用スクリプトのみを配置しても、どのような背景でその実装を選んだのかは読み手に伝わりません。業務システムの導入では、現場の運用状況を把握し、要件定義から検証まで一貫して関わる場面があります。そのため、設計判断の筋道を説明する文書が補足資料として機能します。上流から検証まで一貫して伴走する役割は、発注者側にとってAI導入の頼み方4類型を比較で示されている支援形態の違いを測る重要な評価軸となります。

例えば、編集部が想定した架空の個人制作「公開サンプル規程を使った社内問い合わせ回答候補提示ツール」を考えます。このツールの想定利用者は「社内窓口の担当者」であり、作業内容は「公開資料を確認しながら回答の下書きを作成する初動支援」に限定します。利用者へ直接自動返信を行わない設計にした理由は、担当者が内容を確認していない不完全な回答がそのまま送信される事故を防ぐためです。また、組織内の非公開文書は学習だけでなく、入力、保存、検索の対象にも一切含めない設計境界を設定します。

技術選定の記述では、単に特定のライブラリやモデル名を挙げるのではなく、代替案との比較計画を整理します。例えば「有給休暇の取得手続き」と「年休の申請手順」のような同じ意味を表す語句の揺れに対して、検索機能のみの構成と生成AIを組み合わせる構成を並べます。検索結果の適合性、回答案の読みやすさ、API呼び出し費用の3点について、どのように比較評価を行う予定なのかを計画として記載します。実際の検証を行っていない段階であれば、特定の方式が優れていると結論づけず、評価予定の項目として記述します。さらに、参照元となった規程の条文番号と該当箇所を表示する機能は、担当者が提示された回答候補の根拠を原典と照合して確認できるように設けます。

伝える観点	READMEに記述する内容	確認用の資料・データ
課題と対象範囲	想定利用者、支援する作業、意図して除外した対象外の領域	ユースケース一覧、機能対象外リスト
技術選定の判断	代替手法との比較観点（適合性、読みやすさ、利用費用など）	方式比較メモ、検証計画書
出力の評価方針	テストケース構成、該当なし時の挙動確認、失敗例の記録枠	評価用データセット、テスト実行ログ
運用と制約事項	データ更新手順、障害時の代替動作、実装済み機能と将来計画の区別	環境構築手順、既知の課題リスト

OpenAIのForward Deployed Engineer募集要項（2026年10月19日確認）では、発見、要件定義、設計、構築、本番展開を担当し、本番での定着や評価に基づくフィードバックを重視する職務内容が示されています。またOpenAI東京FDEの応募条件でも触れられているように、単一の実装にとどまらず、運用や評価を見据えた視野が業務で求められます。個人の成果物においても、評価や運用の制約を整理しておくことは、自身の思考過程を第三者に伝える助けとなります。

起動から停止までを示すREADMEの記述例

以下は「編集部作成の架空例・個人制作」です。配布用の実動コードではなく、自身の制作物に合わせて項目を埋めるための未検証の雛形です。コマンドや設定ファイル名は実装環境に合わせて確定させる必要があります。数値実績を創作せず、未検証の項目は実行後に記入する枠として整理します。

# 社内問い合わせ回答候補提示ツール（サンプル規程版）

【制作区分と担当範囲】
- 制作区分: 個人制作（実顧客への導入、業務ヒアリング、本番運用の実績はありません）
- 担当範囲: 課題設定、アーキテクチャ検討、プロトタイプ実装、評価用データセット作成

【課題・利用者・対象外】
- 想定利用者: 社内問い合わせ窓口の担当者（1〜2名を想定）
- 支援する作業: 公開規程から該当箇所を探す時間の軽減、回答案の下書き作成支援
- 対象外とする事項:
  - 質問者への自動返信（担当者の目視確認を経ていない回答の送信を防ぐため）
  - 非公開社内データの取り扱い（入力・保存・検索・モデル学習の対象外とする）

【入力例と期待する挙動】
- 入力例: 「慶弔休暇の申請期限と提出書類を教えてください」
- 期待する挙動:
  1. 該当するサンプル規程の条文番号と抜粋テキストが表示される
  2. 抜粋に基づいた回答の下書き文章が生成される
  3. 規程に記載がない質問には「該当する規程が見つかりませんでした」と返答する

【前提環境とAPI利用条件】
- 実行環境: Python 3.11以上（動作確認OS記入欄: [実行確認後に記入 / 想定OS: macOS, Linux]）
- 外部API条件: OpenAI APIキーが必要です。検証実行に伴いAPI利用料が発生します

【起動手順（未検証の雛形）】
1. リポジトリのクローンと移動
   git clone https://example.com/your-account/fde-sample-tool.git
   cd fde-sample-tool
2. 仮想環境の作成とパッケージ導入
   python -m venv .venv
   source .venv/bin/activate  # Windows環境は .venv\Scripts\activate
   pip install -r requirements.txt
3. 環境変数の設定
   cp .env.example .env
   # .env 内に OPENAI_API_KEY を設定（リポジトリにはコミットしないでください）
4. サンプルデータの取り込みと検索準備
   python scripts/ingest_sample_data.py
5. アプリケーションの起動
   python app.py
   # ブラウザで http://localhost:8000 にアクセスして動作を確認します

【評価実行手順と結果記録枠】
- 評価実行コマンド:
  python scripts/run_evaluation.py --testset tests/sample_queries.json
- 評価用データセット構成（計15問・独自作成）:
  - 規程内に回答が存在する質問: 10問
  - 規程内に対象の記述が存在しない質問: 3問
  - 表記の揺れを含む質問: 2問
- 評価結果記録欄:
  - 正しい該当条文を引用できた割合: [評価実行後に実測値を記入]
  - 「該当情報なし」と正しく判断できた割合: [評価実行後に実測値を記入]
  - 処理時間実測値: [評価実行後に実測値を記入（未計測・未検証）]

【運用想定と制約（実装状態の区分）】
- データ更新: 規程更新時にインデックスを再作成するスクリプトを用意（架空例内の設定として実装済み・実運用での検証は未実施）
- 閲覧権限管理: 担当者別のアクセス制御は未実装（公開サンプル規程のみを対象とするため省略）
- 障害時の代替動作: 外部API接続失敗時は検索一致箇所のみを表示する画面へ切り替え（計画中・未実装）

【停止手順とリソースの削除】
- 停止方法: 実行中のターミナルで Ctrl + C を入力してサーバーを停止します
- ローカルデータの削除: 必要に応じて作成されたキャッシュディレクトリ（.cache/等）を削除します

【既知の制約と確認予定事項】
- 複雑な表組みを含むPDFファイルからのテキスト抽出精度に懸念があり、抽出精度の検証を予定
- 質問内容が曖昧な場合に、不足情報を聞き返す対話機能は未実装

起動から評価までを第三者が手元で確認できるようにする

リポジトリを閲覧するエンジニアは、記述通りの挙動が再現されるかを確認することがあります。前提環境、API利用条件、起動手順、テスト手順、停止方法を順序立てて整えておくことで、作業の手戻りを減らせます。APIキーなどの認証情報は、README本文や公開リポジトリのコミット履歴に含めず、環境変数などで管理する手順を示します。

出力精度の評価を記載する際は、うまく処理できた事例だけでなく、情報が存在しない質問への対応を含めることが重要です。AIが回答を捏造せずに「記載なし」と出力できるかを確認することは、実務での安全性評価に近い視点です。ただし、手元の模擬環境で評価を実行した結果を「業務効率を改善した」という実務成果に置き換えてはいけません。テストケースに対する一致率と、実際の業務現場における導入成果は明確に区別して記述します。

実案件と個人制作で説明できる範囲を分ける

職歴書やポートフォリオをまとめる際、業務として関わった実案件と自身で作成した個人制作では、説明できる境界が異なります。JDSCのFDE求人情報（2026年10月19日確認）では、2年以上の開発経験とともに、曖昧な要件を対話を通じて整理し実装へ進めた経験が必須条件に挙げられています。実案件と個人制作の性質を分けて提示することで、自身の経験を過不足なく伝えられます。

現職や前職の実案件について説明する場合、成果物の扱いは所属先の社内規程および事前の許可範囲に従います。これはソースコードに限らず、システム構成図や面接での口頭説明にも当てはまります。固有名詞を伏せたり内容を抽象化したりしたとしても、無条件に外部へ説明できるとは限りません。事前に共有可能な範囲を確認し、本人が担当した設計や実装の範囲を正確に示します。

一方で個人制作を説明する場合は、自身で設定した前提条件や運用フローを、実際の顧客と合意した実績であるかのように混同させない配慮が必要です。機能の実装状態、評価の実施有無、机上の運用計画をREADME上で分けて書くことで、技術的な判断基準が明確になります。JDSCが求める開発経験と課題整理の経験でも示されているように、対話を通じた整理能力と自発的な実装検証の姿勢をそれぞれ適切に補足資料へ反映させます。