当方が行うこと／行わないこと — 与信審査AIエージェント PoC

契約は準委任、担当は「設計」と「設計レビュー」と理解しております。実務に入る前に、当方が行うことと行わないことを一覧にしておきます。認識が違っている箇所があれば、ご指摘いただければ直します。

担当範囲

区分	行うこと	行わないこと
決定	ロジック・インターフェース・失敗時の動作・判定基準・データ形式を文書で決定します。	—
コード	論点を説明するための例示コード（動作は保証しません）。	成果物リポジトリへのコミット、プルリクエストの作成、当方名義での成果物提出、動作する成果物の作成。
伝達	設計書を孫代表へ提出します。	実装担当の方への、実装方法・細部の直接の指示。
協議	実装担当の方、RoboCo-op様のご担当者との技術的な協議は直接行います。	業務範囲・稼働・期限に関する指示の受領（窓口を通じてお願いします）。
レビュー	設計書に対する適合／不適合の指摘、および指摘管理台帳の作成。	実装品質全般の保証、および修正作業そのもの。
検証	テスト観点の作成。	テストの実施、負荷試験、実測値の取得。
環境	設計・レビューに必要な資料の受領。	閉域端末をお預かりしての作業、環境構築、インフラ設計。

設計を進めるうえでお願いしたいもの

上の一覧は当方が行わないことを含みますので、そのぶんいただきたいものを併せてお示しします。いずれも書面（メール・チャットを含む）でいただければ十分で、お打ち合わせの場を設けていただく必要はありません。

#	お願いしたいもの	これで何が決まるか
1	質問書への書面でのご回答	DataRobot および振り分け君を実装されたご担当・ベンダーの方へ、現在の構成をおうかがいする質問書をお渡ししたいです。内容は「詳細設計で検討する事項」A-7の5点です。トリガーをどこに置けるか、構成をどこまで変更できるかが決まります。
2	検証用のパラメータセット＋期待値	初回の確認で10件程度、本格的な動作確認で50件程度。実在性の要件は項目ごとに分かれます（下記）。あわせて各件に「審査担当の方ならこう判定する」という期待値を添えていただきたいです。期待値がないと、AIの出力が正しいかどうかを測る基準がありません。
3	振り分け後フォルダの実物サンプル（1〜2件）	個人情報はマスキングいただいて構いません。ファイル名の規則（A-6の「C」の衝突）、フォルダ①〜⑤の構成、PDFのレイアウトが確定します。成果物1「インターフェース定義」の入力側そのものです。
4	調査済みPDFの期待出力イメージ	手書き程度で構いません。ご提案資料には「サマリと異常値ハイライト」としかなく、どういう形であれば7分を判断そのものに使えるのかが分かりません。視察 46:35 の「平均で78万2000円でした」がヒントだと考えています。成果物6が確定します。
5	12分審査の実測内訳	審査ご担当の方数名に、1日ストップウォッチで測っていただく程度で十分です。18:01・01:06:49 の12分のうち調査が何分なのかが分からないと、1〜2分にして何が改善するのかを申し上げられません。A-5（起点・終点）とB-1（リードタイム）が同時に解けます。
6	与信ポリシー49項目・統合ポリシー20項目の一覧（項目名のみ）	今回の4項目がその49項目のどこに当たるのかが書面で固定されます。中身の判断は不要で、項目名だけで足ります。

1について、質問書は当方で作成し、お渡しは孫代表を通じてお願いしたいです。また、9月末の設計完了を目指す都合上、ご回答の期限をいただけると助かります。期限までにご回答が揃わない項目は、未決事項一覧に記載したうえで設計を進めます（設計そのものは止めません）。

検証用データについて — 実在性が必要な項目とそうでない項目

個人信用情報そのものをお預かりすることは想定しておりません。実在性が必要なのは会社側の情報だけで、申込者ご本人の情報は実在しなくても検証が成立します。

項目	実在性	理由
会社名・住所・電話番号	必要	ウェブでの実在確認そのものが検証対象のため、実在する企業である必要があります。ただし実際の申込者と無関係な実在企業で構いません。
申込者の個人名	不要	ネガティブ検索は「ヒットする名前」と「ヒットしない名前」があれば検証できます。公開されている人物名で代替可能です。
車両情報	不要	車種・グレードが実在すれば足ります。

ケースの構成についても、全件が正常系ですと検出力がありません。次のような境界のケースを混ぜていただきたいです — 正常（実在・一致）／実在しない会社／公式サイトがない／電話番号の不一致／住所の不一致／同名異人が存在する人名／ネガティブ情報がヒットする人名／グレード未入力。

環境へのアクセスについて（AWS・閉域端末）

AWSのアカウントをお預かりして直接触る形、および閉域の端末をお預かりしてそこで手を動かす形は、いずれもお断りしたいと考えております。設計とレビューは資料と文書で進められる範囲で行います。当方の都合というより、次の理由からです。

変更履歴を1本にしておくため。アクセス権を持つ人が増えますと、障害が起きたときに「誰が何を変えたのか」を特定できなくなります。当方が触れる状態にありますと、実装側は「設計者が変えたのではないか」を排除できず、その逆も同じです。当方が触らないことが、実装側の責任範囲を守ることになります。
個人信用情報に触れる人を増やさないため。CICのデータが流れる環境の権限保有者が増えれば、それだけコンプライアンス承認の範囲が広がります。設計とレビューはアクセスなしで成立しますので、権限を持たない方が承認を通しやすいはずです。
レビューの独立性のため。触れる状態にありますと「設計者がその場で直してしまう」経路ができ、また自己検証になります。

そのかわり、処理時間などの実測値は実装側または貴社側でお取りいただき、ご提供をお願いしたいです。アクセスを持たない以上、当方では測定できないためです。

実装担当の方への直接の指示を行わない理由

指示を行いますと、その実装結果の責任が当方に及びます。設計とレビューを同一の者が担う構成に、さらに実装への指揮が加わりますと、レビューが検査として機能しなくなります。伝達は設計書という1つの経路に限らせてください。技術的な協議は直接行って差し支えないと考えております。

設計には約束が入るということ

設計には「この結果が出ます」という約束が入りますので、設計した側が何も負わない形にはならないと考えております。上の一覧は、当方が何を約束し、何を約束しないかを先に置いておくためのものです。ここが噛み合わないまま進みますと、10月に「これで終わりなのか」の話になってしまいます。

この文書で扱っていないもの
本書は当方の担当範囲についてのものです。PoCとして何を作るか（機能の範囲）は別の資料に分けてあります。
→ 「PoCスコープ外の整理」（4ページ）
→ 成果物の一覧は「設計成果物の合意」をご覧ください。