Agents Please リソース
Agents Pleaseでコードをレビューし、チケットを処理し、Moral Ledgerを追跡し、すべてのエンディングを見つけるために必要な情報をまとめています。
Latest Updates
Discover the newest guides, tips, and content
Agents Pleaseのエンディング:ルート計画と選択肢ガイド
選択肢、チェックポイント、セーブ管理、エンディング検証を網羅したネタバレ配慮のルートガイドで、Agents Pleaseのエンディングを計画しましょう。
Agents Please 承認ガイド:ステップ別ワークフロー
Agents Please gig board:ライブ booking のセットアップガイド
Agents Please契約ガイド:条件・解約・権利
Agents Please 全実績:トラッカー&解除ガイド
Agents Please steam:ストア検索とセットアップガイド
Agents Pleaseのリリース日:2026年の状況と更新ガイド
Agents Please実績:段階別アンロックガイド
実用的なチェックリスト、ルート計画のヒント、取り逃しやすい目標へのアドバイス、整理された記録方法を使って、Agents Pleaseの実績を計画しましょう。
Agents Please エンディング条件:検証ガイド
Agents Please コードレビューガイド:安全なセットアップガイド
この Agents Please コードレビューガイドを使用して、AI 支援レビューの構成、リスクの優先順位付け、自動化を盲信しない修正確認を行います。
Agents Pleaseの仕事ガイド:タスクを段階的に進めるワークフロー
Agents Please初心者ガイド:エージェントの役割と初めてのマッチ
Agents Please 初心者ガイド
Agents Pleaseでは、すべての解決策を自分で書くのではなく、AIエージェントが生成したコードをレビューする役割を担います。各勤務サイクルでは、契約を選び、要求された変更の動作を理解し、生成された差分を確認し、怪しい挙動をテストし、その結果を安全に出荷できるか、修正が必要かを判断します。
毎日のGig Boardを確認する
まずはGig Boardで利用可能な契約を確認しましょう。生成された解決策を開く前に、要求された動作を注意深く読み、コードが実際に何を達成すべきなのかを把握してください。
契約内容を理解する
タスクに記載された想定入力、出力、制限事項、エッジケースを特定しましょう。AIエージェントは、実際の要件を満たしていなくても説得力のあるコードを生成できるため、元の要求を常に念頭に置いてください。
AI生成の差分をレビューする
エージェントの説明だけで結果を判断せず、エージェントが変更した箇所を確認しましょう。変更された条件、戻り値、検証ロジック、ループ、そして要求されたタスク以外の動作まで変えてしまうコードに注意してください。
エージェントの主張を問い直す
エージェントの要約は、実装が動作する証拠ではなく補足情報として扱いましょう。その主張をコードおよび契約要件と直接照らし合わせてください。
テスト入力を実行する
解決策を承認する前に、通常のケースとエッジケースを確認するためのテスト入力を使いましょう。有効なテストは、最も簡単に成功する例だけを確認するのではなく、生成されたコードの前提を意図的に突くものです。
隠れた失敗を探す
珍しい値、誤った前提、境界条件、またはエージェントが言及していない挙動によって解決策が壊れないか確認しましょう。一見小さなミスでも、説得力のあるパッチを誤った承認に変えてしまうことがあります。
修正か出荷かを選ぶ
実装とテスト結果を理解したら、コードを修正すべきか出荷すべきかを決めましょう。判断の根拠は、AI生成の説明の自信ではなく、コードの実際の挙動に置いてください。
一貫したレビュ―習慣を身につける
後の契約でも同じレビュー順序を繰り返しましょう。まず要件、次にコード、その次にテスト、最後に判断です。一貫したレビューを行えば、進行に伴って判断や結果が増える、より複雑なタスクにも対応しやすくなります。
Quick Tips
- まず要件、次にコード、その次にテスト、最後に判断。
- 説得力のある説明は証拠ではありません――証拠は差分です。
- 境界値の入力は、簡単なテストでは見逃す問題を見つけます。
- 気づきにくい小さな編集が、きれいに見えるパッチを誤った承認に変えることがあります。
Agents Please 攻略
Agents Pleaseでは、連続する勤務日に契約を完了し、レビュー判断を下すことで進行します。最も安全な方法は、新しい任務を毎回初めての調査として扱うことです。要求を理解し、エージェントが変更した内容を確認し、実装をテストし、判断を確定する前により広い結果を考慮しましょう。
勤務日を始める
その日に利用できる仕事を開き、Gig Boardに表示された契約を確認しましょう。レビューに取りかかる前に、各タスクの目標を確認してください。
要求された変更を読む
生成されたコードを調べる前に、契約を明確な要件へ分解しましょう。これにより、エージェントが本当の問題を解決したかどうかを判断するための基準が得られます。
提案されたパッチを確認する
AI生成の差分を1行ずつレビューし、プログラムのどの部分が変更されたのかを特定しましょう。条件、検証、出力、失敗処理を制御するロジックには、特に注意を払ってください。
コードと説明を比較する
エージェントがパッチの動作について述べている内容を読み、その主張を実装で確認しましょう。付属の説明が完全に聞こえるというだけで変更を承認してはいけません。
重要なケースをテストする
想定される用途をカバーする入力だけでなく、誤った前提を明らかにする可能性のある値も実行しましょう。テストは、もっともらしく見える解決策と、実際に契約を満たす解決策を見分ける最速の方法です。
レビュー判断を下す
要件と観測された挙動の両方を確認したうえで、適切な修正か出荷かの結果を選びましょう。これらの判断が進行の中心となるループを形成し、その後の展開に影響を与えます。
部署の進行を進める
進行によって責任の範囲と重要性が広がる中で、仕事を完了し続けましょう。後半のタスクでは、一見単純な技術的判断を取り巻く結果に、より注意を払う必要があります。
重要な判断を記録する
1つのパッチが技術的に動作するかどうかを超えた選択に注意を払いましょう。承認の判断や倫理的な決断は、プレイスルーの方向性と最終的な結果に影響します。
Agents! Please? エンディングガイド
Agents! Please? では、コードレビュー中の判断を単なる個別の合否判定として扱いません。承認の選択、問題のある依頼、そしてプレイヤーのより広い倫理的な方向性が後の結果に影響するため、エンディングを目指すプレイでは、最後の一度の選択に頼るのではなく、一貫した意思決定が必要です。
Agents! Please? 実績ガイド
Agents! Please? には、進行状況やコードレビュー作業中の選択に関係する Steam 実績が24個あります。最も効率的なコンプリート方法は、自然に獲得できる実績と、特定の選択やエンディングに関係する実績を分けて考え、ルートを確定する前に重要な分岐点を守ることです。
通常進行
Missable: いいえ契約を完了し続け、ゲームの通常の仕事の進行を進める。
まずは各勤務日を通常どおりに進め、専門的な実績ルートに集中する前にレビューシステムを学びましょう。
コードレビューの決定
Missable: はい生成されたコード変更をどのように判断するかが実績の獲得条件となる場面に到達する。
修正するか出荷するかを選ぶ前に、契約、差分、テスト結果を確認しましょう。必要な決定が別のルートと相反する場合があります。
倫理的な決定
Missable: はい技術的には可能な行動が、より広い倫理的な結果をもたらす場面で、特定の選択をする。
すべての契約を個別の技術的問題として扱うのではなく、目指しているルートに合わせて選択を一貫させましょう。
エンディング実績
Missable: はい特定のエンディングに結び付いた決定パターンに従いながら、プレイを完了する。
エンディングルートは累積する決定を軸に計画し、同時に達成可能な選択関連の実績を同じプレイで獲得しましょう。
別の選択肢に関する実績
Missable: はい別の実績またはエンディングルートで使用した決定とは異なる分岐を選ぶ。
互いに相反する選択は、ほぼ完了したエンディングルートを崩すのではなく、別のプレイで回収しましょう。
コンプリート計画
Missable: いいえメイン進行とエンディング関連の目標を完了した後、残りの実績を獲得する。
相反する選択によって取り逃した実績を確認し、次のプレイではその分岐だけを狙いましょう。
Agents! Please? Gig Board と仕事のガイド
Gig Board は Agents! Please? の日々の仕事の出発点です。各契約では、AIエージェントが提案したコード変更、その説明、利用可能なテスト入力を通して評価するプログラミングタスクが提示されます。まず要求された動作を理解し、次にエージェントが実際に変更した内容を確認し、重要なエッジケースをテストしてから、その解決策を修正するか出荷するかを決めるのが確実な進め方です。
契約の目的を読む
AIエージェントの要約に頼るのではなく、仕事で実際に要求されている動作から確認を始めましょう。コードが受け取る入力、期待される出力や動作、変更してはいけない要件を特定してください。
提案された差分を確認する
エージェントが追加、削除、変更した意味のある行をすべて確認しましょう。一見小さな編集でも、条件、計算、戻り値、制御フローが契約と一致しない形で変わることがあります。
エージェントの主張を確認する
エージェントの文章による説明と、実際のコードを比較しましょう。説明は実装が正しい証拠ではなく、検証すべき主張として扱ってください。
提供されたテストを実行する
契約に用意されたテスト入力を使い、提案された解決策がどのように動作するかを確認しましょう。明らかなテストに通ることは有用ですが、重要な入力をすべて正しく処理できるとは限りません。
リスクのある入力をテストする
境界値、別の分岐、繰り返し処理、誤った条件や計算を明らかにする可能性のある入力に特に注意しましょう。エージェントが中核ロジックを変更した場合、こうした確認が特に役立ちます。
修正か出荷かを決める
実装が契約を満たしていない場合や、テストによって誤った動作が明らかになった場合は、修正を求めましょう。コード、説明、実際のテスト結果が仕事の要件と一致していることを確認してから出荷してください。
進行への影響を考える
契約は孤立したパズルではなく、ゲーム全体の進行の一部です。日々の仕事と部署の進行を続けながら、常に慎重にレビューすることで、誤った承認を避けやすくなります。
Agents! Please? Moral Ledger と選択肢のガイド
Agents! Please? では、Moral Ledger システムを通じて、技術的なレビューの決定と倫理的な結果が結び付いています。重要なのは、コードが単に動くかどうかではなく、実装が実際に行うことに照らして、承認、却下、変更要求のいずれが正当かという点です。繰り返し行う決定は現在の契約を越えて影響する場合があるため、技術的な正しさと、デプロイによって生じる結果の両方を考慮しましょう。
| Choice | Immediate Effect | What to Check | Long-Term Role |
|---|---|---|---|
| 正しい解決策を承認する | レビューされたコードがデプロイ用に承認され、現在の仕事が進行します。 | 実装が契約に一致し、意図した結果を生成し、望ましくない動作を隠していないことを確認します。 | エージェントの主張ではなく、検証済みのコードに基づいて正当な承認を行うパターンを支えます。 |
| 十分なテストをせずに承認する | 重要な動作が検証される前にコードが出荷される可能性があります。 | エージェントの解決策を受け入れる前に、関連する入力を実行し、変更された分岐を確認します。 | 出荷された動作が意図したタスクと一致しなかった場合、軽率な承認が後の結果に影響することがあります。 |
| 修正を求める | 提案された実装は現在の状態では受け入れられません。 | テスト、コード検査、または契約の要件によって実際の問題が明らかになった場合に使用します。 | エージェントが成功したと主張したというだけで出荷するのではなく、欠陥のある作業を修正する姿勢を示します。 |
| 誤解を招くエージェントの主張を却下する | AIの説明と実際のコードの不一致が、レビューの失敗として扱われます。 | 説明を変更されたロジックや実際のテスト出力と一行ずつ比較します。 | 自信に満ちていても誤っているAIの説明に、判断を左右されるのを防ぎます。 |
| コードを動作で判断する | レビューとテストを行った際に、プログラムが実際に何をするかに基づいて決定します。 | 条件、状態の変化、計算、戻り値、テスト結果に注目します。 | 道徳的・技術的な判断を、見た目ではなく観測可能な結果に結び付けます。 |
| デプロイの結果を考慮する | レビューが構文の確認にとどまらず、その実装を出荷することが正しい結果かどうかを問うものになります。 | 技術的には動作しても、要求された目的に反していたり、有害な副作用を生んだりする動作を探します。 | 重要な選択は、ゲーム全体で追跡される後のイベントやエンディング関連の結果に影響することがあります。 |
Agents! Please? コードレビューとテストガイド
コードレビューはAgents! Please?の中心となるスキルです。最も安全な方法は、まず仕事の要件を確認し、エージェントの説明を鵜呑みにせず差分を調べ、変更されたロジックを追跡してから、通常のケースと特殊なケースの両方を試せる入力でテストを実行することです。最終的な判断は、プログラムの実際の動作に基づいて行いましょう。
要求された動作を理解する
まず契約を読み、単純なルールに落とし込みましょう。プログラムにどのような情報を入力し、その結果として何が起きるべきなのかを確認します。これが、以降のすべての変更を判断する基準になります。
説明より先に差分を読む
変更されたコードを直接確認しましょう。プログラムの結果を変える可能性がある、値、条件、ループ、関数の動作、戻り値への経路の変更を探します。
変更されたロジックを追跡する
組み込みテストを使う前に、簡単な入力例を使い、実行順序に沿ってコードを追いましょう。変数の値を記録し、どの条件やループが実行されるかを判断します。
エージェントの説明と比較する
ここで、AIエージェントの説明と実装を比較します。ある動作を修正したと書かれているのに、関連する条件、計算、分岐が依然として異なる動作をしているなら、その食い違いを警告として扱いましょう。
通常のテストを実行する
契約で想定される最も一般的なケースを表す、通常の入力から始めましょう。実際の出力が期待される結果と一致することを確認します。
境界値と別パターンのテストを実行する
異なる分岐に入る入力や、重要な境界値の近くにある入力を試しましょう。こうしたテストによって、1ずれのロジック、誤った比較、考慮漏れ、最も簡単な入力でしか正しく動作しないループなどを発見できます。
無関係な変更がないか確認する
解決策が、要求されたタスク以外の動作を変更していないことを確認しましょう。パッチが1つのテストを解決する一方で、プログラムの別の部分を誤って変更している可能性があります。
修正するか、出荷する
実装が要件を満たしていない、テスト結果が間違っている、またはエージェントの主張と矛盾している場合は、修正を要求しましょう。コードを確認し、その動作が契約と一致しているなら、デプロイを承認します。
Agents! Please? Python風言語ガイド
Agents! Please?では、コードレビューのタスクに実行可能なPython風プログラミング言語を使用します。プレイヤーはプロのプログラマーになる必要はありませんが、基本的な制御フローを理解していれば、怪しい変更をはるかに見つけやすくなります。コードを上から下へ読み、変数の値を追跡し、どの分岐が実行されるかを確認して、最終的な結果を契約で期待される動作と比較しましょう。
変数
score = 10
bonus = 5
total = score + bonus変数には、後続の式や条件で使用できる値が保存されます。差分を確認するときは、エージェントが保存される値を変更していないか、または計算で使われる変数を置き換えていないかを確認しましょう。
Common mistake: 間違った変数を更新する、または最終計算で古い値を使う。
条件分岐
if score >= 10:
result = "pass"
else:
result = "fail"条件によって、どのコード分岐を実行するかが決まります。比較演算子を少し変更するだけで、境界値での動作が完全に変わることがあります。
Common mistake: > の代わりに >= を使う、比較を逆にする、または正しい処理を間違った分岐に置く。
ブール論理
if has_key and door_open:
enter = True論理演算子は複数の要件を組み合わせます。必要な条件がすべて同時に真であるべきなのか、それともどちらか一方で十分なのかを確認しましょう。
Common mistake: and 条件を or に置き換え、分岐が簡単に実行されすぎるようにする。
ループ
for item in items:
total = total + itemループは複数の値に対して同じロジックを繰り返します。変更されたループが合計、カウンター、累積結果に影響する場合は、少なくとも2回の反復を追跡しましょう。
Common mistake: ループ内で累積値をリセットする、項目を飛ばす、または反復を1回多く繰り返す。
カウンター
count = 0
for item in items:
count = count + 1カウンターは、何かが何回発生したかを記録するためによく使われます。初期値と更新する位置の両方が結果に影響します。
Common mistake: 間違った数から開始する、または1つの条件分岐の中でしか加算しない。
関数
def calculate_total(a, b):
return a + b関数は再利用可能なロジックをまとめ、結果を呼び出し元に返します。関数が変更された場合は、内部の計算と返される値の両方を確認しましょう。
Common mistake: 正しい値を計算しているのに別の変数を返す、または必要なロジックをすべて実行する前に返してしまう。
関数の入力
result = calculate_total(4, 6)引数によって、関数のパラメーターに値が渡されます。エージェントが引数の順序を変更していないか、または異なるデータを表す値を渡していないかを確認しましょう。
Common mistake: 位置によって意味が異なる引数を入れ替える。
戻り値
if value < 0:
return 0
return valuereturn 文は現在の関数を終了し、値を返します。return より下のコードはその経路では実行されないため、早期 return は重要です。
Common mistake: 早く return しすぎて、一部の入力に必要なロジックを飛ばしてしまう。
テスト入力
input: 10
expected: "pass"テストを使うと、期待される動作とレビュー対象のコードが実際に生成する結果を比較できます。異なる条件や分岐が関係する場合は、複数の入力を使いましょう。
Common mistake: 簡単な1つのテストに合格しただけでコードを承認し、別の分岐が間違ったままにする。
境界値ケース
value = 10
if value >= 10:
valid = Trueルールの境界値と完全に一致する値は、比較ロジックを確認するのに特に役立ちます。境界値の直前、ちょうど境界値、直後をテストすると、微妙なミスを発見できます。
Common mistake: 間違った比較演算子を使い、入力がしきい値と等しい場合にのみ失敗する。