はじめに 2025年新卒のブランドソリューション開発本部ZOZOMO部OMOブロックの東谷です！　私は筋トレが趣味なのですが、増量期（筋肉をつけるために体重を増やす時期）が終わろうとしています。早く痩せなきゃと思いつつ、つい揚げ物や甘いものを食べ、現実から逃げている今日この頃です。 早いもので入社からもう1年が経ちました。この1年を振り返って一番強く感じているのは、 スクラムは「アジャイル開発の手法」であると同時に、新卒にとっての最高の学習環境だった ということです。 配属直後の自分は、リファインメントの議論についていけず、実装中もどこから手をつけてよいか分からない状態でした。それでも1年後、チームの中でスクラムを一通り回せるようになりました。この変化は、研修や独学だけではなく、スクラムの各イベントそのものに大きく支えられました。 スクラムがよく語られるのは「ビジネス価値を最大化する仕組み」としての側面です。しかし新卒視点から見直してみると、これらはすべて先輩たちの思考プロセスを短時間で観察し、その場で質問できる場でもありました。書籍やドキュメントでは身につきにくい「思考の型」、つまり先輩がどんな問いを立て、何をよりどころに判断しているかという基準があります。これを学べる環境として、スクラムは新卒にとって非常に整った構造を持っていると感じています。 この記事では、「思考の型」を自分が新卒1年目に具体的にどう身につけたかを振り返ってみます。題材として取り上げるのは、プロダクトバックログリファインメント（以下、リファインメント）、スプリントプランニング（以下、プランニング）、モブプログラミングの3つです。前者2つはスクラムイベントで、モブプログラミングはチームで採用している開発プラクティスです。新卒エンジニアには「スクラムは新卒の最高の学習環境になりうる」という視点を、新卒受け入れを担う開発組織には育成設計のヒントを提供できればと思っています。 目次 はじめに 目次 配属直後の自分とチームの環境 スクラム開発で身についた3つの学び 1. リファインメント：機能を「課題解決の手段」として見る視点が身についた 先輩が立てる「問い」が、自分の視野を順に広げていった 議論を経て、機能の質と学びが見えた 2. プランニング：Acceptance Criteriaで「実装の自由度」を制御することを学んだ Acceptance Criteriaで「実装の自由度」を制御する 見積もり精度はAC定義の解像度の問題に集約される 3. モブプログラミング：「事実ベースで実装する」という姿勢が身についた 先輩は事実から方針を決めていた 「事実から始める」という型を学んだ AI時代に、思考の型はどう活きるか おわりに 配属直後の自分とチームの環境 配属前の自分にとって「開発」とは、仕様が決まったタスクを実装することとほぼ同じ意味でした。 学生時代に長期インターンとして参加していたのは、ITベンチャー企業のBtoBプロダクト開発チームでした。そのチームのバックログには仕様まで書かれたタスクが並んでおり、エンジニアはその中から自分でタスクを取って作業する開発サイクルでした。タスクはリーダーが起票していき、起票時点で何を作るかは決まっています。自分の仕事は、それをコードに落とす精度と速度を上げることだと思ってました。 そんな自分が配属先の今のチームに入ったとき、まず驚いたのは開発サイクルの「広さ」でした。 リファインメントでは、プロダクトバックログアイテム（PBI）の目的や受け入れ条件を整理し、チームで認識を揃えながら実装可能な粒度まで要件を具体化します。プランニングでは、スプリントゴールを踏まえてチーム全員で作業内容を確認し、相対見積もりをしながらスプリント内で達成する内容を決定します。開発中はモブプログラミングを通じてリアルタイムに知識共有と意思決定を行います。スプリントレビューでは完成したインクリメントをステークホルダーとともに確認し、次の方向性を議論します。 この1週間のスプリントを、新卒の自分も初日からチームの一員として回すことになります。それまでの開発経験と決定的に違ったのは、バックログにタスクが並ぶ前の段階から、自分も議論に参加するという点でした。 もう1つの驚きは、議論についていくために要求される知識の量です。リファインメントやプランニングでは、複数の前提知識を踏まえた議論が当たり前のように展開されます。例えば、自分の担当しているサービスが他のサービスとどう連携しているか、CQRSで構築されたデータの流れはどうか、認証基盤との関係はどうなっているのかなどです。配属直後の自分は、議論の中で出てくる用語の半分も追えていない状態でした。 「自分が貢献できるだろうか」。最初の数週間、率直に言ってそう感じていたのを覚えています。 ところが、振り返ってみるとこの環境が、自分にとってこれ以上ない学習機会になっていました。スクラムの各イベントが、まさに知識、経験が足りていない新卒にとって最適な学習装置になっていたからです。 スクラム開発で身についた3つの学び ここからは、新卒1年目で身についた3つの学びを、具体的なエピソードとともに紹介します。 1. リファインメント：機能を「課題解決の手段」として見る視点が身についた 私が所属しているチームでは、ZOZOTOWN上でブランド様の店舗在庫を確認し、商品の取り置きができるサービス「 ZOZOMO店舗在庫取り置き 」を開発しています。複数のマイクロサービスが連携し、CQRSを採用しているため、イベントを通じたデータの流れを理解することが開発の前提になるプロダクトです。 配属されてしばらく経った頃、ブランド様の店舗情報をシステム上で更新できる機能を実装しました。それまでは開発チームが手動で対応しており、完了までに3営業日ほどかかっていました。ブランド様を待たせることになり、運用者の認知負荷や作業時間も大きいという課題がありました。 議論に参加する前、私の頭にあったイメージは簡単でした。「入力フォームを作って、POSTで更新するAPIを叩けば完了」。配属されたばかりの私は、機能を「実装するもの」として捉え、実装イメージが浮かんだ時点で完成像が見えたつもりになっていました。 ところが、実際のリファインメントの議論はまったく別の地点から始まりました。 先輩が立てる「問い」が、自分の視野を順に広げていった 最初に出てきたのは、システム構造に対する問いでした。認証基盤との関係、マイクロサービスごとの責務、そしてデータがどのサービス間をどのように流れるのか、といった内容です。私が「POSTを1つ作ればいい」と思っていた機能は、実際には複数のサービスにまたがってイベントを発行し、各サービスがそれぞれの責務でデータを更新していくものでした。CQRSやイベント駆動の設計は独学で吸収するには時間のかかる領域ですが、議論の場で出てくる用語や設計判断についてその場で質問できることで、認知負荷の高い情報を一気に吸収できました。 次に、システム設計が具体化してくると、想定していなかった論点が次々と出てきます。「店舗情報が更新されたことをどう確認するのか」「確認するためにはどのデータが必要か」。考えるべきことが膨らんでいくなかで、先輩から自然に出てきたのが「 この機能はそもそも何を解決するものだったっけ？ 」という問いでした。 そこから議論は、機能を実装する話からユースケースを実演してみる話に切り替わります。実際の運用者の動きを想像し、ときには運用者に直接ヒアリングしながら、ユーザー体験ベースで仕様が具体化されていきました。 例えば、「店舗情報として更新できるデータは何があるのか」を全部洗い出すところから始まりました。さらに「運用者が更新ボタンを押す前に、入力ミスがないと安心できる状態は何か」「更新した後、本当に意図通りに反映されたかをどう確認するか」など、ユーザー体験の細部にまで問いが続いていきます。これらに応える形で、機能の中身が具体化されていきました。 さらに出てきたのが、「この機能を実装した後の恒久的な運用フローはどうなるか？」という問いです。「今回のケース以外にも対応できる汎用性って必要だっけ？」「逆に今回のユースケースに限定すれば不要となる実装ってないっけ？」のように汎用化を考える問いと、削ぎ落とすための問いが、同じ場で同時に飛び交っていたことが印象的でした。 象徴的だったのが、ブランド情報の鮮度をめぐる議論です。ZOZOMOのシステム構成上、店舗が所属するブランド様の情報が変わったとき、システム側は正常に更新されますが、その変更がリアルタイムで運用ツールに表示されない仕組みでした。そのため運用上、「正確なデータを変更しているかどうか確認したい」と運用者から開発側へ問い合わせを受けるケースの発生も予測されました。今回の店舗情報の更新機能を考えるうえで、この運用上の課題へ手を入れる余地があると判断し、ブランド情報を最新状態として取得し直す機能を同じ画面の中で組み込むことになりました。この機能を実装した結果、関連する問い合わせは発生していません。目の前の機能要求だけでなく、運用される将来の状態まで含めて考えることで、機能の質が変わっていく瞬間でした。 議論を経て、機能の質と学びが見えた リファインメントの議論を経て、最終的な機能は、私が当初抱いていたイメージとは大きく違うものになりました。最終的にできたのは、店舗情報の更新作業だけでなく、その前後で必要になる作業まで1画面で完結できる機能でした。 1画面に統合したのは、更新前の確認（店舗IDから店舗名・ブランド名を表示）、更新後の確認（変更後データの表示）、そしてブランド情報の鮮度を保つための再取得機能の3つです。これにより、運用者は別ページに遷移したり、別件で開発側に問い合わせをしたりする必要がなくなりました。効率よく作業できる機能に仕上がっています。 この一件で体感したのは、機能の「核となる実装」は全体のごく一部にすぎないということでした。POSTのAPIとUIという核は確かにイメージできていましたが、それが実際のユーザーへ届きビジネス価値へとつながるまで、想像をはるかに超える議論と設計判断が積み重なっていました。 リファインメントに新卒のうちから参加できたことで、私は機能を「実装するもの」ではなく「課題を解決するもの」として見る視点を、議論の中で自然に身につけることができたと感じています。これは、先輩から受け取った最初の思考の型のひとつでした。 2. プランニング：Acceptance Criteriaで「実装の自由度」を制御することを学んだ リファインメントで十分実装が可能だと判断されると、次はプランニングでスプリントの計画を立て、タスクの洗い出しやタスクの規模を見積もります。配属直後の私にとって、この時間はリファインメント以上に難しいものでした。 規模の見積もりには、チームごとに蓄積されるベロシティ（過去のスプリントでどれくらいの規模を消化できたかという感覚値）があります。「このくらいの規模の変更ならだいたい何ポイント」という相場が、過去の実装経験から自然と形成されていきます。配属されたばかりの自分にはそれがなく、対象機能の核となる変更部分の理解もまだ浅い状態で、規模を出すのは正直難しい作業でした。 では、先輩はどう見積もっているのかなと気になりました。観察して印象的だったのは、実装を頭の中で先取りして見積もるやり方でした。ZOZOMOではDDDやCQRSを採用しているため、これはコードベースを頭の中で走らせる形になります。例えば「Query側のStore集約のUsecaseでデータを整形して、Infra層に店舗集約をUpsertするクエリを書いて、UnitTestとE2Eを書いて…」といったイメージです。見積もりは「数字の当てっこ」ではなく、この工程をどれだけ正確に頭の中で走らせられるかなのだと理解しました。そして、その想像力を支えているのは、過去の実装を積み重ねてきた経験にほかなりませんでした。 Acceptance Criteriaで「実装の自由度」を制御する 想像力と経験がある程度身についた状態で、より規模を正確に見積もり、要件を満たすために考えるべき重要な指標があることに気づいたのは、1年経ってからでした。それが Acceptance Criteria（受け入れ基準、以下AC）の解像度 です。 ACとは、その機能が「完成した」と判断するための条件を具体的に言語化したものです。重要なのは、ACの粒度が実装の自由度をコントロールするということでした。 象徴的だったのが、ブランド様と店舗の紐付けを除外する設定を確認する機能の実装です。これはリファインメントの結果、ブランド様ごとに検索ができ、絞り込んだ結果をExcelとして出力する機能も追加するスコープに広がりました。Excelはメールで該当ブランド様に送り、店舗とブランド様の紐付きが正しいかを確認してもらうためです。 このときのACの一例は、「検索後、Excel出力ボタンを実行したタイミングでポップアップが表示され、絞り込みした店舗の属するブランド一覧がポップアップに表示されること」と定義しました。 このACは、自由度の制限の仕方が絶妙でした。検索のクエリや検索ロジック、Excel生成の方法そのものには制限がかかっていません。より良い実装方法があれば実装時に改善できる余地が残されています。一方で、出力時にポップアップで対象データを一覧表示するという最終的な体験の部分は明確に固定されています。これは複数ブランドを指定して検索できる仕様上、運用者が「どのブランド様のExcelを送ろうとしているんだっけ？」を実行直前に視覚的に確認できる状態を保つことで、ヒューマンエラーを抑えるためです。 ACが「実装の細部までガチガチに固定する文書」になっていると、開発者は工夫の余地を失います。逆にACが曖昧すぎると、実装中に判断を迫られる回数が増え、規模が大きくブレます。ACは、考えてよい部分と考えなくてよい部分を明確に切り分け、実装の自由度を意図的にコントロールするための装置なのだと、この実装を通じて理解しました。 見積もり精度はAC定義の解像度の問題に集約される ACの粒度をこの形でコントロールできていたから、実装中に時間をかけて考える部分と、考えずに型通り進めてよい部分の切り分けが明確でした。結果として、見積もった規模と要件の両方を、ある程度の確度で同時に守れる構造になります。 規模そのものを正確に当てに行くのではなく、ACの粒度をコントロールして実装中の判断回数を制御します。プランニングを1年続けた末に言語化できたのは、「見積もり精度の問題は、その手前のAC定義の抽象度に集約される」という知見でした。 数字を出すこと自体に意識を向けていた1年前の自分から、今は「ACで実装の自由度を制御することで、規模と要件の両立を狙う」ことに意識を向けるようになりました。プランニングの場の捉え方がこのように変わったことが、この1年で起きた最も大きな変化の1つです。ACの粒度を意図的に調整するという考え方も、私のなかに定着した思考の型のひとつです。 3. モブプログラミング：「事実ベースで実装する」という姿勢が身についた リファインメントとプランニングを経て、いよいよ実装フェーズです。私のチームでは実装の多くをモブプログラミングで進めます。複数人が同じ画面を見ながら、ナビゲーター役とドライバー役を交代しつつコードを書いていく形式です。 モブプロから学んだことは数多くありますが、今の自分に最も大きく影響しているのは「 事実ベースで実装する 」という姿勢です。 先輩は事実から方針を決めていた リファインメントやプランニングで要件をどれだけ詰めても、実装段階で「考慮しきれていなかったこと」は必ず出てきます。とくにマイクロサービス間でデータを連携している箇所では、外部要因も絡んで挙動が読みにくくなります。 ZOZOMOでも、他のマイクロサービスとイベントを通じたデータ連携をしています。しかし、さまざまな要因によりイベントの連携順序が入れ替わり、本来連携されるべきデータを正しく届けられないケースもありました。この問題に対処する仕組みを実装した際、モブプロで先輩のアプローチを間近で見たのが印象的でした。 先輩はまず、入れ替わりが起きたデータを全件出してくるところから始めました。一部ではなく全体を並べて共通項を探すと、どの経路の、どのタイミングで入れ替わりが起きているのかという事実が浮かび上がってきます。 そこから先輩が見出したのは、ZOZOMO側の開発基盤にデータが連携される箇所で、入れ替わりそのものを直すという根本的な解決策でした。全件のデータという事実から出発したからこそ見つけられた解決策です。 「事実から始める」という型を学んだ このやり方の何がすごいかというと、 実装の前に「何を解決すべきなのか」が事実として明らかになっている ことです。事実から始めれば「この具体的なケースを直すには何が必要か」という明確な目的が手元にあります。結果として、不要な処理が混ざらず、シンプルでビジネス価値の高い実装にたどり着きやすくなります。 このとき自分が何より学んだのは、「とりあえず動かしてみる」のではなく、手元の事実をしっかり集めてから設計に入るという姿勢でした。新卒1年目で身につけた中でも、実装に向かう前の心構えとして特に役立っている型です。 事実ベースで判断するという姿勢も、モブプロを通じて自分のなかに残った思考の型のひとつです。 AI時代に、思考の型はどう活きるか この1年は生成AIの普及によって「情報を知っていること」自体の価値が一気に下がった年でもありました。ドキュメントを読み込む、仕様を覚える、エラー文を検索する。こうした若手エンジニアの仕事の一部だった作業の多くを、AIがあっという間に肩代わりする時代です。 だからこそ、ここまで紹介してきた「思考の型」の価値が、以前より一段はっきり見えてきた気がしています。ACをAIに書かせることも、実装方針をAIに提案させることもできます。しかし出てきた出力が正しい方向に向かっているかを評価し、軌道修正の指示を出すには、自分の中に判断の物差しが必要です。 思考の型を自分の言葉で持っていれば、それはそのままAIへの的確な指示に変わります。たとえば、3つの学びはそれぞれ次のような指示につながります。 リファインメントで身につけた「これは何を解決する機能か」という問いは、「この機能の目的はこうだから、それに沿った実装案を出して」という指示になる プランニングで身につけた「ACで自由度を制御する」思考は、「実装手段は任せるが、最終的な体験はこう固定したい」という指示になる モブプロで身につけた「事実ベースで判断する」姿勢は、「推測で進めず、まず該当データを全件出してから方針を決めて」という指示になる AIに何を問いかけ、その答えをどう評価し、どこで意思決定するか。その一連の判断は、思考の型を自分の足場として持っている人間にしかできないと思います。 おわりに 1年を振り返って、スクラムは新卒にとって 先輩の思考の型を最速で学べる装置 として機能しました。リファインメントで問いの立て方を学び、プランニングでACの解像度を上げる感覚を掴み、モブプログラミングで事実ベースの実装の進め方を身につけました。一つひとつは技術書を読んでも身につかず、リアルタイムの観察と質問なしには手に入らないものでした。 スクラムは「アジャイルに開発するためのフレームワーク」として語られることが多いです。しかし新卒として配属された自分の視点からは、先輩たちの思考にアクセスする頻度を最大化する仕組みであり、かつAI時代に価値を持ち続ける能力を集中的に育てる仕組みでもありました。 これから配属を迎える新卒エンジニアの方には、配属先のチームがスクラムで動いているなら、それを「ただの開発手法」とは思わずに思考を盗む1年にしてほしいと伝えたいです。技術知識を吸収する場としてだけでなく、思考の型をコピーする場として向き合うと、得られるものの密度が大きく変わります。 新卒受け入れを担う開発組織の方には、スクラムを生産性の文脈だけで評価せず、新規メンバーの学習装置としての側面にも目を向けてもらえると嬉しいです。先輩の思考に高頻度で触れられる場が組織にあるかどうかは、人材の立ち上がりスピードに大きな差を生むはずです。 自分自身は、まだスクラムから学べることの入口に立ったところだと思っています。2年目以降は、観察する側だけでなく、自分の思考の型を他のメンバーに見せていく側にも回っていきたいです。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

本日、 Amazon Bedrock と Claude Platform on AWS で Claude Fable 5 が利用可能になったことをお知らせいたします。Claude Fable 5 は、Mythos レベルの機能をすべてのお客様が利用できるようにするとともに、より広く安全に使用できるように設計された強力な保護手段を備えています。Fable 5 は、テストされたほぼすべてのベンチマークで最先端であり、ソフトウェアエンジニアリング、ナレッジワークタスク、ビジョンにおいて並外れたパフォーマンスを発揮し、野心的で長期にわたる作業向けに構築されています。 Claude Fable 5 on Bedrock を使用すると、既存の AWS 環境内で構築し、推論ワークロードをスケールできます。また、Claude Platform on AWS を通じて Claude Fable 5 を使用することも可能です。これにより、Anthropic のネイティブプラットフォームエクスペリエンスが得られます。 Anthropic によると、Claude Fable 5 は、AI モデルで達成できることの段階的な変化を表しています。このモデルの利点は次のとおりです。 長時間の非同期実行 – Claude Fable 5 は、以前のモデルでは維持できなかった複雑なタスクを処理し、コーディングやナレッジワークのタスクを介入なしに長期間実行します。 高度なビジョン機能 – Claude Fable 5 は、ファイルや PDF にネストされた図、チャート、表を理解します。これにより、財務、法務、分析、建築、ゲームにおけるリサーチや文書を多用する作業が可能になります。コーディングでは、モデルは忠実度の高い設計を実装し、ビジョンを使用してそのアウトプットを目標と照らし合わせます。 積極的な自己検証 – 本モデルは学習内容に基づいてスキルを自己更新し、独自のハーネスと評価を開発します。 Claude Fable 5 には、誤用のリスクが高い特定の領域でのパフォーマンスを制限する保護手段が含まれています。サイバーセキュリティ、生物学、化学、健康に関連する有害なプロンプトは、代わりに Opus 4.8 からの応答を受け取るようにフォールバックします。Anthropic はより強力な保護手段を開発することで、Claude Fable 5 の最先端機能のほぼすべてへのアクセスを拡大することができます。制限のない同一モデルが Claude Mythos 5 であり、精査された少数のお客様のみが利用できます。 動作中の Claude Fable 5 モデル Claude Fable 5 は Amazon Bedrock と Claude Platform on AWS の両方でご使用いただけます。この投稿では、Amazon Bedrock へのアクセス方法と使用方法に関するガイダンスをご紹介します。Claude Platform on AWS に関するガイダンスについては、 ドキュメント にアクセスして詳細をご確認ください。 Amazon Bedrock の使用を開始するには、 Anthropic Messages API を使用してプログラムでのみモデルにアクセスし、Anthropic SDK を介して bedrock-runtime エンドポイントまたは bedrock-mantle エンドポイントを呼び出します。 AWS コマンドラインインターフェイス (AWS CLI) と AWS SDK を介して bedrock-runtime の Invoke API と Converse API のみ引き続き使用できます。 コンソールのサポートは近日開始予定です。 Claude Fable 5 モデルにアクセスするには、モデルを呼び出す前に Data Retention API を使用し、 provider_data_share を設定してデータ共有を有効にする必要があります。リリース時には、この設定用のコンソールユーザーインターフェイスはありません。 curl -X PUT https://bedrock-mantle.us-east-1.api.aws/v1/data_retention \ -H "x-api-key: <your-bedrock-api-key>" \ -H "Content-Type: application/json" \ -d '{ "mode": "provider_data_share" }' bedrock-runtime エンジンを使用している場合は、以下のサンプルスクリプトを実行してください。 curl -X PUT https://bedrock.us-east-1.amazonaws.com/data-retention \ -H "Authorization: Bearer <your_bearer_token>" \ -H "Content-Type: application/json" \ -d '{ "mode": "provider_data_share" }' このモードでは、Amazon Bedrock は推論データをモデルプロバイダーの要件に従って保持し、共有できます。Anthropic では、30 日間のインプットとアウトプットの保持と、人間によるレビューが必要です。詳細については、「 Amazon Bedrock の乱用検知 」をご覧ください。 まずは Anthropic SDK for Python から、 bedrock-mantle エンドポイントで Messages API を使ってみましょう。Anthropic SDK をインストールします。 pip install anthropic Claude Fable 5 モデルを呼び出すための Python コードのサンプルは次のとおりです。 import anthropic client = anthropic.Anthropic( base_url="https://bedrock-mantle.us-east-1.api.aws/anthropic", api_key= <your-bedrock-api-key> ) message = client.messages.create( model="anthropic.claude-fable-5", max_tokens=4096, messages=[ { "role": "user", "content": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions", }, ], ) print(message.content[0].text) 詳細については、複数のユースケースとさまざまなプログラミング言語に対応した Anthropic Messages API のコード例 と ノートブックの例 をご覧ください。 Bedrock コンソー ルで Claude Fable 5 を使用できるようになりました。 Playground で Claude Fable 5 を選択してテストします。 bedrock-mantle におけるコンソールサポートは近日中に実装予定です。 また、Claude Fable 5 を bedrock-runtime エンドポイントの Invoke API と Converse APIと併用することもできます。AWS SDK for Python (Boto3) を使用して Converse API を呼び出し、統一されたマルチモデルエクスペリエンスを実現する例を次に示します。 import boto3 bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1") response = bedrock_runtime.converse( modelId="global.anthropic.claude-fable-5", messages=[ { "role": "user", "content": [ { "text": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions." } ] } ], inferenceConfig={ "maxTokens": 4096 } ) print(response["output"]["message"]["content"][0]["text"]) 詳細については、AWS SDK を使用して Amazon Bedrock ランタイムを使用する方法を示す コード例 をご覧ください。 知っておくべきこと 役立つと思われる重要な技術的詳細をいくつかご紹介します。 モデルアクセス – Claude Fable 5 へのアクセスは、すべての AWS アカウントに徐々に拡張されます。アカウントにまだアクセスできない場合は、Bedrock の使用状況にもよりますが、すぐに有効になります。このモデルにすぐにアクセスしたい場合は、通常の AWS サポートにお問い合わせください。 価格設定 – 有害なプロンプトが Fable 5 ではなく Opus 4.8 にルーティングされた場合、支払うのは Opus の料金のみです。会話の途中でリクエストがブロックされた場合、最初のトークンは Fable レートで請求され、その後のトークンはOpus レートで請求されます。詳細については、「 Amazon Bedrock の料金 」ページにアクセスしてください。 データ保持 – 同等かそれ以上の機能レベルを持つBedrock の Fable 5、Mythos 5、および将来のモデルでは、Anthropic は Mythos クラスモデルのすべてのトラフィックを 30 日間保存する必要があります。データを一定期間保持することで、Anthropic は、1 回のやりとりでは見えない悪用のパターンを検出できます。データ保持を選択すると、データは AWS のデータとセキュリティの境界から外れます。 Claude Mythos 5 on Bedrock (限定プレビュー) – 脆弱性の発見、ドラッグデザイン、バイオディフェンススクリーニングなど、サイバーセキュリティとライフサイエンスに関する Anthropic の最も有能なモデルも使用できます。これらのドメインは二重使用であるため、現在アクセスは制限されています。詳細については、 モデルカードのドキュメント をご覧ください。 今すぐご利用いただけます Anthropic の Claude Fable 5 モデルは、本日から、米国東部 (バージニア北部) および欧州 (ストックホルム) リージョンの Amazon Bedrock でご利用いただけます。今後のアップデートについては、 リージョンの全リスト をご確認ください。Claude Fable 5 は、北米、南米、欧州、アジアパシフィックリージョンの Claude Platform on AWS でもご利用いただけます。 Claude Platform on AWS の Amazon Bedrock API を使用して Claude Fable 5 をお試しいただき、 AWS re:Post for Amazon Bedrock に、または AWS サポートの通常の連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

お知らせ 2026年7月からオンラインでサーバーレスに関するワークショップを4件開催します。ぜひ、ご参加ください。 7/7 10:00〜12:00  Kiroによるサーバーレス開発 7/9 10:00〜12:00  イベント駆動アーキテクチャ・アプリケーションの構築 7/14 10:00〜12:00 AWS Lambda durable functions によるコード型ワークフロー 7/16 10:00〜12:00 AWS Lambda マネージドインスタンス 本記事は2026年2月6日に公開された Building fault-tolerant applications with AWS Lambda durable functions を翻訳したものです。翻訳はSolutions Architectの加藤 諒が担当しました。 ビジネスアプリケーションでは、顧客オンボーディング、決済処理、大規模言語モデル推論のオーケストレーションなど、確実に実行する必要がある、あるいは長期間の待機が必要な、複数のステップを連携させることがあります。これらは、一時的な中断やシステム障害があってもプロセスを完了する必要があります。そのため、開発者はビジネスロジックではなく 進捗の追跡、障害の処理、外部イベントの待機時のリソース管理のメカニズムの実装といった付加価値を生まない作業に時間を費やしています。 re:Invent 2025で、 Amazon Web Services (AWS) は AWS Lambda durable functionsを発表しました。これは、使い慣れたプログラミング言語を使用して耐障害性のある複数のステップが必要なアプリケーションとAIワークフローを構築するための新しい機能です。基本的に、durable functionsは通常のLambda関数であるため、Lambdaの開発および運用プロセスは引き続き適用されます。ただし、Lambda関数を作成する際に、durable executionを有効にすることで、進捗のチェックポイント保存、障害からの自動回復が可能になります。また、human-in-the-loopプロセスなどの長時間実行タスクを待つ間、最大1年間実行を一時停止できます。 標準のLambda関数を使用する場合、コードは単一の呼び出しで開始から終了まで実行されます。実行中のいずれかの時点で障害が発生した場合、呼び出し元のイベントソースによって関数全体を再試行する必要があります。実行間で保持する必要がある状態は、明示的に保存および取得する必要があります。これは通常、 Amazon DynamoDB や Amazon Simple Storage Service (Amazon S3 )などの外部ストレージサービスを使用して行われます。さらに、同じイベントの重複（同時）呼び出しを防ぎ、イベントの処理を継続しながら安全に更新をデプロイする対策を講じる必要があります。 対照的に、Lambda durable functionsでは、開発者はイベントハンドラーで「Steps」や「Waits」などのdurable operationsを使用して、進捗をチェックポイントし、障害を処理し、Lambda関数のコンピュート料金を発生させることなく待機期間中に実行を一時停止します。これらのdurable operationsとそれらから任意で返される状態は、durable execution backendで管理され、 自動的に永続化されます。実行中に障害が発生した場合、または一時停止後に関数が実行を再開した場合、Lambdaは関数を再度呼び出し、イベントハンドラーを最初から実行することで以前の状態を復元（リプレイ）しますが、完了したdurable operationsはスキップします。開発者向けがこのチェックポイント/リプレイの仕組みを簡単に利用できるようにするため、Lambda durable execution SDKを使用してイベントハンドラーをラップまたはアノテーションできます。具体的には既存のLambdaコンテキストにcontext.step()やcontext.wait()などのいくつかの新しいメソッドが追加されます。さらに、context.waitForCallback()などのメソッドを使用して、”human-in-the-loop”シナリオなどの外部ジョブや非同期プロセスを待機できます。SendDurableExecutionCallbackSuccessまたはSendDurableExecutionCallbackFailureレスポンスがLambda APIに送信されるまで実行は一時停止されます。 AWS Serverless Application Model (AWS SAM) で、AWS Quick Start Templateを使用して新しいdurable functionを作成します。 sam init コマンドで実行できます。 Lambda durable functionsは、 AWS Cloud Development Kit (AWS CDK) 、 AWS Command Line Interface (AWS CLI) 、 AWS CloudFormation 、およびTerraformなどの他のinfrastructure as code (IaC)フレームワークでもサポートされています。 ユーザーオンボーディングを実行する以下の関数を考えてみましょう。まず、ユーザーの入力データに基づいてユーザープロファイルを作成し、次に検証のためにメールを送信し、ユーザーがメールアドレスを確認するか、24時間のタイムアウトに達するまで待機します。最後に、確認を送信します。 import { DurableContext, withDurableExecution, } from '@aws/durable-execution-sdk-js'; export const handler = withDurableExecution( async (event: OnboardingEvent, context: DurableContext) => { try { // Create user profile const profile = await context.step("create-profile", async () => createUserProfile(event.email, event.name) ); // Wait for email verification via callback const verification = await context.waitForCallback( "wait-for-email-verification", async (callbackId) => { // Send email to user and pass callbackId await sendVerificationEmail(profile, callbackId); }, { timeout: { hours: 24 } } ); // Send confirmation and welcome email const result = await context.step("complete-onboarding", async () => { if (!verification || !verification.verified) return { ...profile, status: 'failed' }; await sendWelcomeEmail(profile.email, profile.name); return { ...profile, status: 'active' }; }); return result; } catch (error) { // omitted } } ); durable functionsには、組み込みでステップ用の カスタマイズ可能なエラー処理があります。たとえば、プロファイルが正常に作成され検証されたが、確認の送信時に一時的なエラーが発生した場合、そのステップが再試行されます。再試行では、プロファイル作成やコールバックなど、以前に完了したチェックポイントはスキップされます。確認送信ステップ内のコードのみが再度実行されます。 次に、durable functionを含めるためにAWS SAMテンプレートを更新します。関数にDurableConfig設定を含めることで、Lambda durable functionを作成します。現在、後からLambda関数にdurable configurationを追加することはできないことに注意してください。ExecutionTimeoutは、暴走やデッドロックといったアプリケーションバグから保護するために、durable executionがタイムアウトする時間を定義します。この設定は、単一の呼び出しが実行できる時間を定義するinvocation timeoutとは別です。単一関数呼び出しの最大invocation timeoutは15分で変わりません。Lambda durable functionsでは、SDKでの待機機能や自動再試行を使用する場合など、通常、1回の’durable executionにつき複数の呼び出しが発生します。非同期呼び出しを使用する場合、ExecutionTimeoutを最大1年間設定できます。 RetentionPeriodInDaysは、実行完了後にdurable executionの実行データが利用可能な期間を定義します。 AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Resources: UserOnboardingFunction: Type: AWS::Serverless::Function Properties: FunctionName: UserOnboardingFunction CodeUri: ./src Handler: index.handler Runtime: nodejs24.x Architectures: - x86_64 MemorySize: 256 Timeout: 60 // 1回のInvocationに対するタイムアウト DurableConfig: // この設定によりdurable functionsになる ExecutionTimeout: 90000 // durable execution全体のタイムアウト（25時間） RetentionPeriodInDays: 7 UserOnboardingFunctionRole: Type: AWS::IAM::Role // omitted for brevity また、関数に必要な権限を含める必要があります。たとえば、マネージドポリシー AWSLambdaBasicDurableExecutionRole を設定します。このポリシーはセキュリティを向上させるためにチェックポイントとログの作成/取得のための最小限の AWS Identity and Access Management (IAM) アクションのみを許可します。したがって、他の（durable）関数を呼び出したり、コールバックを管理する場合はこれでは権限が不足します。詳細については、 ドキュメント を参照してください。 関数をデプロイする前に、AWS SAM local invokeを使用してローカルでテストできます。 AWS SAMは関数をローカルで呼び出し、 context.waitForCallback() に到達するまでイベントハンドラーを実行します。コールバックを完了するために、AWS SAMはコールバックを必要とするdurable functionsをローカル実行した際に対話的にコールバックの返却ができます。この例では、コールバックを完了するために Success レスポンスを送信します。レスポンスに関連データを含めることもできます。画面上のガイドを使用して直接レスポンスを送信するか、別のプロセスから別のAWS SAM CLIコマンドを使用してレスポンスを送信できます。 sam local callback succeed <your-callback-id> --result '<your data>' AWS SAMを使用してdurable functionsの実行履歴を取得できます。これには、以下のサンプルコードに示すように、ステップ、コールバック、待機時間に関する詳細が含まれます。 sam local execution history <execution-arn> 必要にに応じて、代わりにコールバックにFailureレスポンスを送信し、コード内でそれらのエラーを処理できます。 sam local callback fail <your-callback-id> --error-data '<your data>' たとえば、後続のステップで補償ロジックを定義している場合にそれの動作を試すことができます。 関数が意図したとおりに動作することを確認できたので、 sam deploy コマンドを使用してAWSにデプロイします。 Lambda durable functionの呼び出しには、エイリアスやバージョンなどの修飾された Amazon Resource Name (ARN) が必要です。速度優先のプロトタイピングやローカルテスト以外では、 $LATEST 修飾子を使用しないことをお勧めします。明示的なバージョンを使用することで、リプレイが実行開始時と同じコードで常に実行されることが保証されます。これは、決定論的実行を確保し、実行中に関数コードを更新する際の不整合を防ぐためです。 お好みのパッケージマネージャーを使用して、durable execution SDKを関数コードにバンドルすることをお勧めします。SDKは高速に進歩しているため、新機能が利用可能になったときに依存関係を更新できます。 アプリケーションの構築に使用できる、Lambda durable functions SDKの その他のdurable operations があります： waitForCondition() ：条件が満たされるまで関数の実行を一時停止します。たとえば、APIでポーリングされるジョブのステータスなどです。これを機能させるには、waitStrategyとステータスをポーリングするチェック関数を提供します。 parallel() ：同じ関数内で複数のdurable operationsを並列実行し、最大同時ブランチ数や望ましい障害動作などの設定可能なオプションを提供します。これにより、同時非同期アクションの耐久性とチェックポイント管理が合理化されます。 map() ：提供されたマッピング関数に基づいて、配列の各項目に対してdurable operationとチェックポイントを作成します。項目は同時に処理されます。 invoke() ：別のLambda関数を呼び出し、その結果を待機します。SDKはチェックポイントを作成し、ターゲット関数を呼び出し、呼び出しが完了すると関数を再開します。これにより、関数合成とワークフロー分解が可能になります。 詳細については、 開発者ガイド を参照してください。 Lambdaコンピュート料金は、リプレイを含むすべての呼び出しに適用されます。待機操作を使用する場合、関数は実行を一時停止し、Lambda関数の実行が再開されるまで実行時間料金は発生しません。また、durable operations、書き込まれたデータ、データ保持に対しても課金されます。Lambda durable functionsの料金について詳しく知るには、 Lambda料金 ページを参照してください。 最新のリージョン可用性については、 AWS Capabilities by Regionページ をご覧ください。 AWS Lambda durable functionsは、使い慣れたプログラミングパターンを使用して簡単に耐障害性のある長時間実行アプリケーションの構築するために、Lambdaのプログラミングモデルを拡張します。Lambda durable functionsを使用して、チェックポイントとエラー回復を自動的に処理する組み込みメソッドを使い、お好みのプログラミング言語でマルチステップワークフローを記述できます。これによりシンプルなアーキテクチャを維持したまま、ビジネスロジックに集中できます。また、課金は実際に処理を行っている時間のみなのでコストを最適化できます。 Lambda API、 AWS Management Console 、AWS CLI、AWS CloudFormation、AWS SAM、AWS SDK、およびAWS CDKを使用して、Python、Node.jsまたはJavaベースのLambda関数用のdurable functionsを構築できます。 開始するには、 Lambda Developer Guide をご覧いただくか、 re:Invent breakout session をご視聴ください。