業務用スクリプトの依頼文に入力・出力・エラー処理のルールを入れる

01コードを受け取る前に task description を完成させる

良い request には、長い role instruction よりも具体的な work rules が含まれます。「files をきれいに整理して」だけでは、どの folder を読むか、result を何と命名するか、duplicates をどう扱うか、overwrite してよいかが決まりません。この記事では scope を小さな task に限定します。1週間分の synthetic work logs を team ごとに集計します。result は、再利用可能な request と input file、expected-result file です。

02作業を6項目に分ける

「time per item」が実際に何を意味するかも書く必要があります。この synthetic example では、すべての input minutes を、その row の completed count に対応する work time と定義します。waiting time や unfinished work の時間が含まれる場合、この average の意味は変わるため、まず work definition を固定してください。

03依頼文を書く順序

1. automation の scope を1つの result に絞ります。files の収集、集計、email 送信を一度に混ぜず、この result は per-team summary file とします。
2. input の key names, data types, units を書きます。たとえば completed は integer、time は minutes 単位の integer と明記します。
3. real names と internal paths を削除した original を使うのではなく、synthetic sample を作成します。names を変更しても transactions や unusual values から data が特定されることがあるため、example 全体を最初から作ります。
4. sample の expected result を自分で計算します。この段階で、sum してから divide するのか、row ごとに average するのかを決めます。
5. errors, empty input, division by zero, existing output files の handling rules を書きます。
6. request を送る前に conflicting instructions がないか確認します。すべての values は integers と書いた後で、blanks を自動的に 0 に変えるような指示を追加しないでください。

04input と expected result を対にする

Design team は 5 items と 140 minutes なので、time per item は 28 minutes です。30 と 25 minutes という per-row values の単純平均である 27.5 minutes を使うと、item counts の違いが反映されません。Operations team は 4 items、80 minutes、20 minutes per item です。Support team は 0 items なので計算できる average がなく、null とします。

input-sample.json と expected-output.json は、この違いを示す pair です。JSON は structured data の format であり、null は number 0 とは異なります。この区別は Python 公式 json documentation に記載されている value mapping でも確認できます。

05そのまま編集して使える依頼文

다음 조건을 만족하는 로컬 Python 스크립트를 작성해 주세요.

[업무 목적]
한 주의 작업 기록을 팀별로 합쳐 완료 건수, 작업 시간 합계(분), 건당 작업 시간(분/건)을 확인합니다.
이 요청의 모든 기록은 합성 샘플입니다. 실명, 고객 정보, 계약 내용, 사내 경로, 계정 키는 포함하지 않습니다.

[실행 환경과 범위]
Python 3 표준 라이브러리만 사용합니다. 외부 패키지 설치, 인터넷 접속, 유료 API 호출, 이메일 전송은 하지 않습니다.
현재 작업 폴더의 input.json만 읽습니다. 하위 폴더 탐색, 원본 수정, 파일 삭제는 하지 않습니다.
새 output.json을 만듭니다. output.json이 이미 있으면 덮어쓰지 말고 이유를 알려주며 종료합니다.

[입력 형식]
UTF-8 JSON 배열입니다. 각 행에는 record_id, team, completed, minutes 네 키만 있습니다.
record_id는 중복되지 않는 비어 있지 않은 문자열입니다.
team은 설계, 운영, 지원 가운데 하나입니다. 알 수 없는 팀은 임의로 바꾸지 않습니다.
completed와 minutes는 0 이상의 정수입니다. 문자열 숫자, true/false, null, 누락 값은 허용하지 않습니다.
입력 배열은 비어 있어도 됩니다. 한 행의 오류라도 있으면 전체 집계를 중단합니다.

[입력 샘플]
[
  {"record_id":"S001","team":"설계","completed":3,"minutes":90},
  {"record_id":"S002","team":"설계","completed":2,"minutes":50},
  {"record_id":"O001","team":"운영","completed":4,"minutes":80},
  {"record_id":"H001","team":"지원","completed":0,"minutes":0}
]

[처리 규칙]
팀별 completed와 minutes를 각각 합합니다.
minutes_per_completed = 팀 작업 시간 합계 / 팀 완료 건수 합계입니다.
행별 평균을 다시 평균하지 않습니다. 건수가 0이면 minutes_per_completed는 JSON null입니다.
평균은 계산 후 Decimal의 ROUND_HALF_UP 방식으로 소수 둘째 자리까지 반올림해 JSON 숫자로 저장합니다.
출력에는 입력에 나타난 팀만 넣고, 팀 순서는 설계 → 운영 → 지원으로 고정합니다.
빈 입력의 출력은 빈 배열 []입니다.

[기대 결과]
[
  {"team":"설계","total_completed":5,"total_minutes":140,"minutes_per_completed":28.0},
  {"team":"운영","total_completed":4,"total_minutes":80,"minutes_per_completed":20.0},
  {"team":"지원","total_completed":0,"total_minutes":0,"minutes_per_completed":null}
]
JSON 숫자는 28과 28.0의 표기가 달라도 같은 값으로 비교합니다.

[오류 원칙]
파일 없음, 잘못된 JSON, 배열이 아닌 최상위 구조, 중복 record_id, 필수 키 누락,
추가 키, 허용되지 않은 팀, 음수/문자열/불리언 숫자를 발견하면 성공 결과를 만들지 않습니다.
오류 메시지는 행 번호(1부터 시작)와 필드 이름, 오류 이유만 출력하고 입력 내용 전체를 출력하지 않습니다.
입력 오류를 0으로 바꾸거나 잘못된 행을 조용히 건너뛰지 않습니다. 종료 코드는 실패를 나타내야 합니다.

[답변 형식]
먼저 목적, 입력, 출력, 오류 처리, 남은 가정을 짧게 요약합니다.
그 다음 완성 스크립트와 실행 방법, 이 샘플의 기대 결과를 제시합니다.
요구사항끼리 충돌하거나 업무 의미를 확정할 수 없으면 코드를 쓰기 전에 해당 쟁점만 질문합니다.
실제로 실행하지 않았다면 실행 완료라고 쓰지 않습니다.

他の work に再利用するときは、team names だけを変更しないでください。purpose、input definition、formula、0 と blank values の意味、expected result も変更します。input sample と expected result が一致しない場合、AI がどちらを reference として扱うか不明確になります。

06送信前に確認する

• file name、read scope、output location が明記されていますか？
• すべての field について data type、unit、allowed values が設定されていますか？
• average の denominator と、rounding を行う timing が分かりますか？
• missing, duplicate, zero-count, empty-array cases がそれぞれ別に定義されていますか？
• sample は real sensitive information を含まずに work structure を示していますか？
• 人が sample result を説明できますか？
• 実行していないものを実行したと主張しないよう依頼しましたか？

OWASP は input format と values の business meaning の両方を確認することを説明しています。この記事ではその区別を request に取り入れ、「integer か」「0 以上か」「allowed team か」を別々に定義します。これらを request に書いたからといって、返された code が実際にその rules を実装しているとは限りません。

07回答が一貫しなくなる一般的な原因

08この資料で確認したことと次のステップ

request は implementation のための agreement document です。code が正しく動くか、files を安全に扱うか、real work data に適しているかは、受け取った code で別途確認する必要があります。この資料では synthetic sample の expected values を Python で確認し、request に required items が含まれていることを確認しました。AI service に依頼した結果や generated code を実行した結果は含みません。

• request.txt: 上記の完全な request
• input-sample.json: sensitive information を含まない4 rows の synthetic input
• expected-output.json: hand calculation と Python check に一致する expected result
• prompt-checklist.txt: requests を書くための checklist
• README.txt: files を読む順序

References は 2026-09-19 に公式 pages で確認しました。Python と OWASP の documents は input format と validation principles を裏付けるものであり、AI service の answer quality を保証するものではありません。

実行・検証の記録

Windows local Python 標準ライブラリ; 公式 sources を 2026-09-19 に確認

• 4 synthetic input rows の team ごとの count, time totals, averages を独立して計算し、expected-output.json と比較しました
• 0 items の Support team の average が null であることを確認しました
• request の input, output, sample, error, sensitive-information exclusion items と JSON syntax を確認しました

サイト全体の執筆・検証方針

参考資料

説明と例は独自に作成しました。関連する動作や概念は、以下の公式資料で確認できます。

• Python 公式ドキュメント · json module ↗ (New tab)
• OWASP · Input Validation Cheat Sheet ↗ (New tab)