株匏䌚瀟マむナビ デゞタルテクノロゞヌ戊略本郚のブログ - TECH PLAY

TECH PLAY

株匏䌚瀟マむナビ デゞタルテクノロゞヌ戊略本郚

株匏䌚瀟マむナビ デゞタルテクノロゞヌ戊略本郚 の技術ブログ

å…š243ä»¶

このシリヌズでは、圓瀟のデゞタルテクノロゞヌ戊略本郚デゞ戊に所属する瀟員が、「なぜ圓瀟を遞んだのか」「入瀟しお䜕を感じたのか」を率盎にお届けしたす。入瀟前の期埅や䞍安、入瀟埌のギャップや魅力を通じお、働く環境を具䜓的にむメヌゞしおいただける内容です。 ■執筆者プロフィヌル職業PdM,PjM瀟䌚人歎7幎目※2026幎珟圚マむナビ歎1幎目※2026幎珟圚所属組織プロダクトマネゞメント統括本郚前職フヌドデリバリヌプラットフォヌム運営䌚瀟 はじめに PdMやPjM・デゞタルサヌビスの䌁画・ディレクション職皮の垌望者向け マむナビぞの転職を怜蚎されおいる方に気になるだろうポむントを茉せおいきたす 結論 デゞ戊を遞んでよかったなず思っおいる なんで転職しようずしたの 仕事をするからには瀟䌚に良い圱響を䞎えたい。 良い圱響を䞎えるからには、より倧きなむンパクトを出したい。 そんな動機から、toC向けデゞタルサヌビスの䌁画・ディレクション職からキャリアをスタヌトしたした。 ステヌクホルダヌ瀟内倖やデザむン・開発者等ず協業しお、成果物が䞖に出お、盎接的に数倀で結果を確認でき、 スキルが䌞びればそのサむクルがどんどん倧きくなる、領域が深たり広がっおいく...ずいう、 短期のやりがい、䞭長期の成長実感や明確なキャリアパス䌁画→ディレクション→PJM→PdMがなんだかゲヌム感芚で、䞖の同職皮の皆さんは皋床の差はあれそういったポむントモチベに業務を楜しんでいるのかなず思いたす。 私ずしおは、PdMずしお残りの仕事人生どんなキャリアを描こうか迷っおいる時期で、 プラむベヌトの転機、前職の転機など、さたざたなファクタヌが重なったこずもあり、転職を考えた次第でした。 転職の軞は メむンテヌマ 前職を継続しお、より䞊䜍職マネゞメント等や経営サむド等の別領域ぞのチャレンゞなど考えたしたが、 より倧きいプロダクトを担圓したい・できるようになりたい気持ちが倧きな軞でした。 ここでいう倧きなプロダクトずは、 より利甚者が倚く、利甚シヌンも倚く、総合的にナヌザヌの人生に䞎える圱響が倧きいサヌビスを指したす。 䟋えばGoogleで蚀えば、怜玢も音楜も動画も、端末や䌁業のクラりド、䌁業の各サヌビスの機胜など様々シヌンで掻甚され、倚くの方に圱響しおいたすAmazonずか色々ありたすよね。日本だず楜倩、LINEダフヌ、リクルヌトなど様々いわゆるスヌパヌアプリ。 こういったサヌビスの特城ずしおは、1個のプロダクトにずどたらず、シナゞヌのある他プロダクトも続々立ち䞊げお、連携、総合的で連続したサヌビスをナヌザヌに提䟛しおいたす。 䞀個のプロダクトを磚きこむこずも圓然倧事ですが、頭打ちは必ずありたす。最終的にボタンの倧きさずか色味のABテストくらいしかやるこずなくなるな...ずかは垞々思っおいた より倧きな䟡倀を生み出すためのプロダクト間連携、シナゞヌの創出は今埌のトレンドになるだろうな、そういったシナゞヌ創出の経隓は䞀PdMずしおの将来的な生き残り戊略ずしお倧事だなずいう目論芋ず、単玔に耇雑で面癜そうよりむンパクト出したい自分の仕事軞ずも合うため、志向するポむントでした。 サブテヌマ もう䞀個、こちらはサブ的なテヌマですが、 AIの掻甚がトレンドの今、業務内にずどたらず、AIを掻甚した新芏プロダクト・既存プロダクトの機胜の改善を志向し、実践しおいる䌁業に飛び蟌んで、知芋を吞収、あわよくば実践・経隓を詰めるこずも志向ポむントでした。 色々な職業のAIによる代替可胜性が瀺唆、文字通り日進月歩で倉わるAIトレンドなどなど、日々目の前の業務に取り組んでいる䞭で、AIに觊ったり・業務・サヌビス掻甚を考える時間は前職だず環境的にあたり取れたせんでしたから、焊燥感は募るばかりでした。 AI掻甚の専門郚眲があっお、昚今のAIトレンドを専属でキャッチアップし、ナレッゞを組織暪断でシェア、堎合によっおは業務で関係できるような䌁業は倧きな魅力を感じたした。 なんでデゞ戊を遞んだの 倧きなプロダクトの0→1を経隓できるこず AI関連の専門郚門がありナレッゞが組織を跚いで共有・協業できるこず 仕事環境が良いこず 倧きなプロダクトの0→1を経隓できる プロダクト統括郚では、toBのプロダクトをメむンに倧小さたざたな芏暡の案件を扱っおいたす。 それらの特城は、新芏の立ち䞊げ・運営改善、そしお各皮マむナビサヌビスずの連携によるシナゞヌ創出にありたす。 䟋えば、担圓しおいるマむナビ TalentBaseずいうサヌビスは、SmartHRに代衚されるようなHR総合プラットフォヌムです。 䌁業の人材管理および、それに掟生した教育研修、採甚等に掟生し、各皮マむナビサヌビスずの連携創出を目䞋の目暙ずしおいたす。 その他にも、将来的なマむナビサヌビスの非連続的成長の糧ずしお、先進的な事䟋の研究開発・PoCを実斜、結果劂䜕で新芏実装などの、ボトムアップ型の0→1案件なども担圓しおいたす 就職や転職、アルバむトや医療犏祉、採甚管理、教育研修など、マむナビグルヌプは事業の軞をなす耇数のプロダクトがあり、それらの非連続的な成長のため、グルヌプ間のシナゞヌ創出は䞭長期蚈画の柱の䞀぀です。 倚様なステヌクホルダヌず協業しお、耇雑か぀圱響の倧きな案件を担圓できるこずは、倧きな魅力でした。 AI関連の専門郚門がありナレッゞが組織を跚いで共有・協業できる AI戊略宀ずいう郚門があり、日倜AIのトレンドを远い぀぀、各皮マむナビサヌビスに取り蟌んだり、業務に取り入れたりなど実践しおいる郚門です。 同じデゞ戊内の郚門であり、距離感も近く、ナレッゞを埗る機䌚、そもそもナレッゞが蓄積される環境でもあっお、非垞に貎重です。 そもそも、党瀟的にAIツヌルの導入、利掻甚の掚進、ガバナンス・運甚ルヌルの策定浞透ず、かなりの熱量で取り組んでいるこずも倧きなポむント。 仕事環境が良い 珟実味な話ですが、仕事環境も倖せない芁玠ですね。 定時は7時間30分なので、8時間の䌁業ず比べるず毎日30分短いこずはずんでもないこずです。 絊䞎氎準は同職皮・職胜垯でも高氎準にあたるず思いたした。 リモヌトワヌクもあり、か぀取埗も容易。圚宅比率50%の目安こそあれ、子育お䞖代の突発的な事由などにおいおは柔軟に調敎可胜なため、運甚ルヌルの芋た目の堅さに察しお実態は非垞に優しいです。 ずはいえ、職堎環境は非垞に充実しおいるデュアルモニタヌ、モニタヌアヌム、個人ブヌス倚数でオンラむン䌚議容易ので、むしろ業務効率向䞊のため意欲的に出瀟できる䞋地は敎っおいたす。 犏利厚生が前職・前々職比范ですが、非垞に倚く、色々掻甚させおもらっおいたす。 倧芏暡ECプラットフォヌムを運営する他瀟ずも、最埌たで迷いたしたが、最終的にデゞ戊を遞びたした。 入瀟前の䞍安は兞型的なJTCで、システムはレガシヌだよず又聞きしおいお䞍安だった 入瀟を決めおから、前職の䞊長に蚀われたこず 「ずはいえ、マむナビは結構レガシヌだよ䞊長のか぀おの郚䞋がマむナビ出身だったそう」の蚀葉はかなり響いお、最埌たで悩んだポむントでした。 囜内倧手のチャットサヌビス䌁業での経隓を持぀䞊長の助蚀もあり、䞍安に感じる点はありたした。 あなた皋の人が蚀うなら...ず 仕事の進行等で前職ずは比にならない開発面、䌁画面でのハヌドルがあり、倧倉なのかな... ちゃんず胜力を発揮したり、キャリアを積んでいけるだろうか...ず䞍安でした。 ずはいえ、ビゞネスサむドに寄っお、経営レむダヌの胜力を匷化しおいきたい思惑もあり、 䞊述の仕事内容や環境面から、マむナビに飛び蟌むこずを決意。 結果、 実際そうだけれども、党瀟的に課題ず捉え、解決に向けお絶賛皌働しおいる過皋だったずわかりたした。 今この瞬間、名だたるテックカンパニヌのような超モダンな環境、ずは蚀えないですが、 経営局レベルで問題意識をもち、珟堎レベルで解決に向かい実行段階にあるこずは、䞍安を抱えおゞョむンした䞀䞭途入瀟人間ずしお非垞に安心できる材料です。 システム 䞀䟋ずしお、システム面に぀いお。 今たでは䞀個のプロダクトをそれぞれ担圓の郚門が磚きこむずいう経営方針の郜合、 プロダクト数がずおも倚く、か぀マスタがプロダクトごずに独立しおいるなど、あるあるな特城がありたす。 たた、開発におけるベンダヌ䟝存の構造今たでの経営合理性に基づく話なので、課題ずいうよりか前提など。 これに぀いおは、゚ンゞニアブログの蚘事等がより参考ずなるのでざっくり申し䞊げるず、 それを解消し、よりマむナビサヌビスの成長に貢献するこずがデゞ戊の存圚理由です。 珟圚進行圢で様々な取り組みがラむンナップされ、着実に匷力に実行されおいるずころです。 組織颚土 たた、組織颚土的な面ですが、 瀟員1䞇人をかかえる倧䌁業特有の特城かなず思い、 むしろ䞭途入瀟瀟員においおは、他䌁業での経隓を求められるシヌンかなず思っおたす。 䟋えばステヌクホルダヌが単玔に倚いです。 これに぀いおは、新卒入瀟から長幎貢献しお圚籍されおいる瀟員の比率が倚いため、 ある事象の確認・承認に぀いおは誰に決裁・浞透を図るべきかサポヌトいただけたす。 さらに、マむナビでの経隓が長く、他䌁業のやり方を知らない瀟員が倚いずいうこずは、 旧来のやり方の螏襲が倚いずいうこずで、 そういったシヌンに䞭途入瀟瀟員の経隓を絡めおアップデヌトしおいくような、 たさに組織の倉化を求められおいるなず感じるこずが倚いです。 なので、䜓制や組織文化的にも既存瀟員ず䞭途入瀟瀟員で二人䞉脚で頑匵っおいこう リスペクトしおいたすな空気を肌身に感じたす。 統括 マむナビは党瀟・組織レベルで、ポゞティブな倉化を望み、実際に倉化しおいるず感じたす。 停滞感や固執ずいった空気はなく、唟棄されたす。 むしろ、レガシヌをモダナむズする過皋にノヌリスクボトムアップで個人のリ゜ヌス頌りではないずいう意味でゞョむンできる環境は、むしろ䞀瀟員ずしお倧きな糧になるのではず皮算甚しちゃうくらいです。 マむナビはそういった、意欲旺盛でチャレンゞングなあなたの゚ントリヌを心埅ちにしおいたす。 是非、䞀緒に働きたしょう 他にも気になる点、深堀りしたい点ありたしたら、人事の方経由で質問いただいおも構いたせん。気軜にアプロヌチしおくださいね おたけ - 入瀟しおおどろいたこず 瀟内コミュニケヌションがかなり豊富です。 瀟内報、teamsの゚ンゲヌゞ機胜、懇芪䌚、組織・組織暪断の勉匷䌚など。 懇芪䌚が四半期レベルで1回以䞊あり、2個䞊のレむダヌ局ずの接点も豊富です。 1䞇人ほどの瀟員がいたすが、さたざたなチャンネルで組織を超えた亀流の機䌚があるので、様々な知芋を吞収できる颚通しの良さはすごく驚きたした。 採甚情報に぀いお デゞ戊では、珟圚䞀緒に働くメンバヌを募集しおいたす。 詳现な仕事内容や募集職皮、働く環境に぀いおは、 採甚ペヌゞ をご確認ください。
このシリヌズでは、圓瀟のデゞタルテクノロゞヌ戊略本郚デゞ戊の瀟員が、業務やプロゞェクトを通じお感じおいる「仕事の䟡倀」ず「瀟䌚的意矩」を玹介したす。顧客や瀟䌚ぞの貢献実感、手応えを芚えた瞬間を取り䞊げ、働く意味をより具䜓的にお䌝えしたす。 はじめに 筆者がこのブログを執筆しおいるのは1月䞋旬。 ”そんなに雪が降らない方”の岐阜にある実家の䞡芪からは、どこか自慢げに「雪降ったわ」ずLINEメッセヌゞを頂く季節ずなりたした。 私はマむナビにデヌタサむ゚ンティストずしお新卒入瀟し、雪解けの頃にはデゞ戊圚籍歎が䞞4幎になる人間です。 「私がデゞ戊で芋぀けたやりがい」ずいうテヌマに䜵せお、やりがいっお生み出す䟡倀っおに察する珟時点での考えを共有できればず思いたす。 筆者プロフィヌル 所属デゞタルテクノロゞヌ戊略本郚 AI戊略宀 AI゜リュヌション郚 入瀟時期2022幎4月 新卒入瀟 職皮デヌタサむ゚ンティスト 業務内容 䞻にマヌケティング領域のAI・デヌタ掻甚プロゞェクト掚進・実装を担圓。 その他、瀟内デヌタ利甚ナヌザ向けの技術支揎・生成AI関連のガバナンス敎備に関する業務も行った経隓がある。 その他特蚘事項 䞀般瀟団法人デヌタサむ゚ンティスト協䌚 スキル定矩委員䌚に所属。 瀟倖むベント・倧孊講矩での登壇頻床が高く、過去は四半期に1回ほど。 䟡倀の定矩 「私がデゞ戊で芋぀けたやりがい」シリヌズでは、デゞ戊メンバヌが「自分の仕事が瀟䌚や顧客にどんな䟡倀を生み出しおいるず感じるか」をアりトプットしおいたす。 どんな䟡倀、の前に業務䞊の䟡倀は䜕なのかに぀いお私の考えを共有したす。 よく「IT職は成果が売䞊に盎結しないから業瞟評䟡が難しい・評䟡されない」ず蚀われるず思いたす。これは営業職などの目暙が定量的に瀺しやすい職皮ずの比范で語られる話ですが、売䞊が䜕によっお生たれおいるかに぀いお考えるず、䟡倀に近づく気がしたす。 営業職は顧客の「賌入刀断」によっお「売䞊」が生たれる ↓抜象化 業務は察象者の「ビゞネス䞊ポゞティブなアクション」を匕き出せたら「䟡倀」になる 営業職は、顧客の心を動かしお「買う」ずいう行動を匕き出し、その察䟡ずしお売䞊を埗おいるず考えられたす。 そう考えれば、我々の仕事も党く同じです。 「すごいモデルを䜜った」「分析レポヌトを出した」こず自䜓が䟡倀なのではありたせん。それを芋た瀟内の誰かが「蚈画を倉曎しよう」「この斜策を始めよう」ず意思決定し、具䜓的なアクションを起こした瞬間にこそ、䟡倀が生たれるのではないかず考えたす。 ぀たり、「察象者のポゞティブなアクションを匕き出すこず」。 これこそが、職皮を問わず共通するビゞネスの䟡倀であるず定矩できるず私は考えたす。 「むメヌゞのしやすさ」 では、どうすれば盞手のアクションを匕き出せるのでしょうか 最近、そのヒントになる出来事がありたした。冒頭でも少し觊れた「雪」の話です。 ちなみに導入の小噺を読んだ皆さんは、「雪降ったわ」がどれくらいの降雪量だったず想像したしたか そんなに降らない方なら、5㎝ そんなにずは蚀っおも、癜川郷はめっちゃ3ずか積もるから1 このテキストでは降雪量を具䜓的にむメヌゞするこずは難しいように感じたす。 䞀方、私が最近芋かけたJR東日本の運転蚈画の案内を芋おいただきたいです。 出兞『JR東日本なるほどQ&A Guide 自然灜害雪』 https://www.jreast.co.jp/saferelief/operationguide/pdf/snow.pdf 降雪はみられるがすぐ溶ける皋床・地面にうっすら積もる皋床ずいった「皋床」の衚珟 2぀のケヌスを瀺す「パタヌン」の提瀺 むラストで雪による地面の透過床を芋せる「可芖化」 があるこずによっお、私たちは瞬時に降雪の状態をむメヌゞするこずができたす。 むメヌゞができるず、リモヌトワヌクぞの切り替え刀断などのアクションも取るこずができたす。 この話ず同じく、マむナビのデヌタサむ゚ンティストずしおは、 瀟内ナヌザの「状況をむメヌゞできる状態」を匕き出せたら「䟡倀」になる ずいう堎面が倚いように私は感じおいたす。ナヌザが担圓しおいるサヌビスの状態や斜策の効果、盎近の未来ずいった芋えおいない状況を晎らすこずが圹割のひず぀であり、それができたら䟡倀になるずいうのが、私の珟状の回答です。 前提敎理が長くなりたしたが、マむナビDSの䟡倀をむメヌゞできたでしょうか ここからは私の業務を玹介し、䟡倀を求める䞊での意識ずやりがいを共有できればず思いたす。 業務玹介 この章では 倪字 はすべお「むメヌゞ→䟡倀」に繋がる芁玠になるように蚘茉しおいたす。 MMMのモデル構築による広告運甚最適化 Web広告やTVCMなど、倚岐にわたる広告斜策の䞭で「本圓に効いおいる広告はどれか」ずいうのは、意倖ず芋えにくいものです。 そこで私は、MMMマヌケティング・ミックス・モデリングを甚いお、 広告効果 の掚定を行いたした。 具䜓的には、メディアごずの 貢献床 を数倀で可芖化し、さらに「来月、予算配分をこう倉えればKPIはこれくらい䌞びる」ずいうシミュレヌション提瀺を行いたした。 ※このプロゞェクトに関しお登壇した過去のむベントレポヌトは こちら 結果ずしお、マヌケティング担圓者が「なんずなく」ではなく「根拠を持っお」予算配分を倉曎するずいう、アクションを匕き出す足がかりにはなったのではず思いたす。 瀟内生成AI利甚ガむドラむンの曎新 生成AIは匷力なツヌルですが、セキュリティリスクや瀟䌚的責任があるため、珟堎は利甚に二の足を螏みがちでした。私は、ガむドラむンの策定を通じお「どんなケヌスなら利甚しおいいのか」「どのツヌルなら業務利甚OKか」ずいう 境界線 を明確に定矩したした。 ※この業務に関しお振り返ったブログは こちら 「この条件なら利甚可胜」ずいう 基準 をクリアにしたこずで、瀟員が迷わず安党に生成AIを掻甚できる環境アクションできる状態を敎えるこずができたした。 日々のデヌタ掻甚に関する問い合わせ 瀟内からは日々、「デヌタを䜿っおこんなこずがしたい」ずいう盞談が寄せられたす。 過去を遡るず100回以䞊盞談䌚を実斜したず思いたす。 しかし、初期段階ではアむデアが抜象的で、実珟可胜かどうかも分からないこずがほずんどです。 これに察し、 そのデヌタは取埗できおいないから、たずは蚈枬から始めたしょう その目的であれば、AIではなく集蚈で十分です ずいったアドバむスを行い、 実珟ぞの道筋 を具䜓化したす。 盞談者の頭の䞭にあったむメヌゞを「 実行可胜な蚈画 」ぞず解像床を高めるこずで、プロゞェクトの着手や、あるいは早期の撀退刀断ずいった次の䞀歩を埌抌ししおいたす。 たずめ ここたで、私の考える「䟡倀」ず具䜓的な業務に぀いおお話ししおきたした。 ビゞネスの䞖界は、たるで雪の日のように芖界が悪く䞍確実なこずばかりです。 䞊手いこず蚀った颚 「本圓にこれでいいのか」ず誰もが刀断に迷い、立ち止たりそうになる瞬間がありたす。 私たちデヌタサむ゚ンティストの仕事は、デヌタによっお「今の状況」や「進むべき道」を、誰もがむメヌゞできる圢にしお届けるこずではないかず思いたす。 そしおむメヌゞを受け取った盞手のアクションが芋えたずき、それは䟡倀ずなり、成果であり、やりがいに繋がるず思いたす。 ここたでの話が、マむナビDSのキャリア”むメヌゞ”に繋がれば幞いです。 採甚情報に぀いお デゞ戊では、珟圚䞀緒に働くメンバヌを募集しおいたす。 詳现な仕事内容や募集職皮、働く環境に぀いおは、 採甚ペヌゞ をご確認ください。
このシリヌズでは、圓瀟のデゞタルテクノロゞヌ戊略本郚通称デゞ戊で働く瀟員が、どのようにスキルを䌞ばし、キャリアの幅を広げおきたのかを玹介したす。キャリアチェンゞの背景や挑戊のプロセス、日々の孊びを通じお、デゞ戊で描けるキャリアの可胜性をお䌝えしたす。 「スキルアップをしよう」 近幎よく耳にする蚀葉ですよね。 VUCAの時代ず呌ばれる倉化の激しい珟代においお、たすたす重芁芖されるようになっおいたす。 これを読んでくださっおいる方の䞭には、スキルアップのためにデゞ戊ぞの転職を考えおいる方もいるかもしれたせん。 でも、よく考えるずスキルアップっお結局なんのためにするんだったっけずふず思いたす。 業務を効率化するため。仕事の幅を広げるため。キャリアの遞択肢を増やすため   理由は人それぞれですが、私にずっおは 「自分の䞖界が広がっおいく面癜さを感じるため」 なのではないかず思い始めおいたす。 今回は、私がそう思えるようになったきっかけずなった、あるプロゞェクトに挑戊したお話をしおみたいず思いたす。 この蚘事で分かるこず デゞ戊にある「挑戊を歓迎する」颚土 郚門をたたいだプロゞェクトで、どんな仕事に觊れられるのか 未経隓でも挑戊しおみたら「意倖ずできた」になる話 スキルアップを「矩務」ではなく「䞖界が広がる䜓隓」ず捉えられるようになったプロセス プロゞェクトに挑戊したきっかけ 私は通垞業務でWEBディレクタヌ職ずしお、自分の担圓サむトの応募数向䞊を目的に、メヌルマガゞンやサむトのUIUX改善に向けた斜策の䌁画・蚭蚈および改善に携わっおいたす。 毎日PCず向き合いながら自サむトず数倀やデヌタを芋比べながら、斜策を緎る日々。 そんな日々を過ごしながらも、私の頭の䞭にはじわじわず違和感が広がっおいきたした。 「このサむトを䜿うナヌザヌの顔を、私は芋たこずがない  」 数字だけ芋お刀断しお良いのだろうか 数字が䞊がったこずを喜んで、それで本圓にナヌザヌのためになっおいるのだろうか ずっず前に䜜られたペル゜ナを頌りに、なんずなく斜策を進めおしたっおいないだろうか  。 そんなこずをぐるぐる考えおいた頃、CXマヌケティング統括本郚の党䜓䌚議で「ナヌザヌリサヌチを行うプロゞェクトを立ち䞊げるのでメンバヌを募集したす」ずいう案内を聞きたした。 気が付いた時には、 勢いで手を䞊げおいたした 。 プロゞェクト抂芁 このプロゞェクトは、「 むンタビュヌやアンケヌトを通したナヌザヌの生の声を聞き、ナヌザヌが本圓に求めおいるものを探るこずで、サヌビス改善に぀なげるこず 」を目的ずしお発足したした。 最終的にはデゞ戊党䜓にリサヌチの颚土を根づかせるこずもゎヌルずしおいたす。 メンバヌは課長1名䞀般メンバヌ2〜3名の少人数。 党員が自ら手を挙げお参加し、玄1幎掻動したした。 実斜内容䞀郚抜粋 ■むンタビュヌ 蚭問蚭蚈 リクルヌティング オンラむンむンタビュヌ27名 オフラむンむンタビュヌ1名 結果の瀟内共有 ■アンケヌト 蚭問蚭蚈 アンケヌト3回 結果分析・共有 ■KSF策定・分析 3C / PEST / 5Forces KSFの策定 ■颚土醞成 勉匷䌚・ワヌクショップ開催 事䟋共有瀟内蚘事 むンタビュヌ䌎走支揎 ※䞊蚘はチヌム党䜓での実瞟になりたす 手探りで進むプロゞェクト 私を含め、メンバヌ党員がリサヌチは未経隓。 それでも、誰かがやり方を教えおくれるわけではなく、 自分たちで調べお、やっおみお、改善する ずいう進め方でした。 掻動内容は倚岐にわたり、3〜4人ずいう䜓制でそのすべおに関われるのは倧きなやりがいでした。 勘違いから始たるナヌザヌむンタビュヌ この掻動範囲の䞭でも特に自分にずっおの倧きな挑戊ずなったのが、ナヌザヌむンタビュヌでした。 実は、プロゞェクトに立候補した時点では、このプロゞェクトをアンケヌト調査だけをやるものだず勘違いしおいたした。 プロゞェクト開始埌に「どうやらむンタビュヌもやるらしい。むしろむンタビュヌがメむンらしい  」ず気が぀いたのです。 もずもず人芋知りで話すこずに自信がない私は、堎をリヌドする必芁のあるむンタビュヌに戊々恐々。 なぜプロゞェクトに自薊したんだろうず埌悔した時期もありたした。 しかしながら自薊した手前、怖気づいおやらない蚳にもいきたせん。 瀟内で緎習盞手を探し、Youtubeで孊び、原皿を぀くり、緊匵で震えながら第1回目のむンタビュヌに臚みたした。 未知の自分ずの遭遇 初回は緊匵で蚀葉が぀っかえながらも、なんずか乗り切った ずいう感じで、自分がむンタビュヌしおいる動画を芋返すのもかなり苊痛でした。 ですが、プロゞェクトメンバヌず毎回振り返りをし、孊びを共有しあい、2回目、3回目ず重ねるうちに䞍思議ず慣れおいきたした。 そしお次第に「 あれこれ意倖ず自分に合っおいるのかも   」ず思い始めたのでした。 ナヌザヌむンタビュヌを通しお数字やデヌタでは分かりきらない生の声に觊れられるこずや、盞手の話を聞きながらナヌザヌが朜圚的に䜕を望んでいるのか、今の自分たちのサヌビスに足りないものは䜕かを考えながら深掘りしおいくプロセスは、非垞に興味深いものでした。 そしお、こうやっおナヌザヌず向き合うこずで、競合の埌远いをするだけではないサヌビスを䜜っおいくこずができるのではないか、ずわくわくしたのでした。 プロゞェクトぞの挑戊を経た孊び ①苊手ず思い蟌んで避けがちなものに、面癜さがあるかもしれない 私は、仕事においお新しいこずに挑戊しおみたいずいう欲がある䞀方、これたでは自分ができそうだず事前に確信できる範囲のこずに挑戊しおきたように思いたす。 ですが今回は、「ナヌザヌむンタビュヌ」ずいう、本来なら自分の苊手意識から避けおいそうな領域に、思いがけず飛び蟌むこずになりたした。 それが、結果的にたたたた新しく面癜いず思えるものに出䌚えるこずになったのです。 「自分はこれが埗意」「自分はこれが苊手」ず思い蟌んでいるだけなのかもしれない。 思い蟌みで、ただ芋ぬ面癜いものに出䌚えないのは勿䜓ない 、ず思えるようになりたした。 ②挑戊は䞀人でやらなくおもいい このプロゞェクトを䞀人でできたかずいうず、やはり難しかったず思いたす。 ナヌザヌむンタビュヌ以倖にも、アンケヌトや瀟内ワヌクショップなど党おが初めおのこずでしたし、䜕よりナヌザヌむンタビュヌがあたりにも自分にずっお心理的にハヌドルに思えたからです。 その䞭でも、同じプロゞェクトのメンバヌず共に勉匷し改善点を共有しあい進めおいくこずで、䞀人で挑戊しおいるわけではない、ず思えたした。 自分から孊び実践する動きは倧事ですが、でもすべおを䞀人でやろうず思う必芁はない。 むしろ、個人個人の挑戊を軞に互いに共有しあうこずで、チヌム党䜓で助け合っお進むこずができる。 組織で働くずいうこずは、互いの埗意分野を発揮しながら、䞀人ではできないこずを協力しあっお成し遂げおいくこず だずいうこずに、改めお気が付く機䌚ずなりたした。 ③キャリアは気になったこずに手を䌞ばしおいたら自然ず圢になるもの 以前はこの先のキャリアを明確に決めなくおはならないのではないか、ずいう気持ちがありたした。 そしお、䜕をやればいいか、䜕をやりたいか䞊手く決めきれない状態にもどかしさを感じおいたした。 しかし、今回、自分が苊手だず思っおいたこずに面癜さを芋出す、ずいう経隓をしお、 今この先のキャリアを明確に決める必芁などないのではないか ず思い始めたした。 「キャリアは、気になったこずに手を䌞ばしおいたら自然ず圢になるもの」ずいう感芚に倉わったこずで、これからも自分の「やっおみたい」ずいう気持ちを倧事にしおいければそれで良いような気がしおいたす。 VUCA時代に、楜しみながら自分だけのキャリアを築く 「自分ひずりでスキルアップができるのか」 これは、私が䞭途入瀟しお1週間ほどの頃、OneNoteに残した蚀葉です。 圓時は、倉化が激しい時代の䞭で自埋的に孊び続けなければならないずいう、静かな焊燥感のようなものがあったのかもしれたせん。 しかし今思うのは、スキルアップは必ずしも「自分ひずり」でやるものではないずいうこず。 だから私はいた、「ずにかく自分が面癜くお楜しいず思える仕事をしおいきたい」ずいうシンプルな気持ちを軞にしおいたす。 自分の興味を軞に楜しみながら仕事をすれば、い぀の間にかスキルは぀いおくるし、これたでやったこずのない業務や関わったこずのない人ず仕事ができるこずが、玔粋に嬉しいです。 そうやっお自分の䞖界が少しず぀広がっおいくこずを楜しんでいれば、い぀の間にかその積み重ねが、自分にしかないキャリアになっおいくず信じおいたす。 最埌に 私の䟋が、「デゞ戊で挑戊しおみたい」ず思っおいる方の参考になれば嬉しいです。 あなたの䞖界が広がるきっかけが、デゞ戊にあるこずを願っおいたす。 お埅ちしおおりたす ■執筆者プロフィヌル職業WEBディレクタヌ瀟䌚人歎5幎目※2026幎珟圚マむナビ歎3幎目※2026幎珟圚所属組織CXマヌケティング統括本郚前職WEB制䜜䌚瀟 ■執筆者プロフィヌル 職業WEBディレクタヌ 瀟䌚人歎5幎目※2026幎珟圚 マむナビ歎3幎目※2026幎珟圚 所属組織CXマヌケティング統括本郚 前職WEB制䜜䌚瀟 採甚情報に぀いお デゞ戊では、珟圚䞀緒に働くメンバヌを募集しおいたす。 詳现な仕事内容や募集職皮、働く環境に぀いおは、 採甚ペヌゞ をご確認ください。
このシリヌズでは、圓瀟のデゞタルテクノロゞヌ戊略本郚デゞ戊の瀟員が、業務やプロゞェクトを通じお感じおいる「仕事の䟡倀」ず「瀟䌚的意矩」を玹介したす。顧客や瀟䌚ぞの貢献実感、手応えを芚えた瞬間を取り䞊げ、働く意味をより具䜓的にお䌝えしたす。 本蚘事の察象者 マむナビのSE業務に興味がある方 新卒がどのような業務に取り組んできたのか興味がある方 もちろんそれ以倖の方も 倧・倧・倧歓迎 です 自己玹介 2023幎月に新卒入瀟したTです。今は瀟䌚人3幎目です2026幎月時点 珟圚は、スカりト系の転職サヌビスである 「マむナビスカりティング」の運甚・保守 を担圓しおいたす ♩ 執筆者による抂芁 この蚘事の執筆者は、入瀟埌から珟圚たでの担圓業務を振り返りながら入瀟時の動機を果たすこずが出来たのか、に぀いおたずめおいたす。 この蚘事を読むこずで、株匏䌚瀟マむナビにおける 「裁量を持った仕事ぞの取組み」 や 「具䜓的な業務内容」 に぀いお知るこずができ、マむナビでSEずしお働くこずの魅力をより深く知るこずが出来たす。 入瀟時の動機 ・toC向けのサヌビスを持぀事業䌚瀟でシステム蚭蚈・䌁画に携わりたい ・裁量を持っお働きたい 執筆者の業務 ・業務芁件→システム芁件の䜜成 ・セキュリティ察応 ・デヌタ可芖化 ・瀟内からの問い合わせ察応 ・ベンダヌコントロヌル マむナビで働くこずの魅力 ・裁量をもっおto C向けサヌビスの改善に携われる ・自らが埗た知識・経隓をもずした提案が歓迎される颚土がある ・知識を埗るための補助曞籍賌入などもある 👇👇👇👇👇 蚘事を読んでさらに詳しく知る 👇👇👇👇👇 それではここから入瀟前珟圚に至るたで時系列順に取り組んできたこずなどを振り返っおいきたす。 入瀟する前 私は23卒の新卒ずしお入瀟したした。 入瀟するからには、䜕かしら䌚瀟に入る動機がありたすよね 私が圓時掲げおいた入瀟動機は以䞋点でした。 ① toC向けサヌビスにシステム蚭蚈・䌁画ずしお携わるこずが出来るこず ② 幎次の若いうちから裁量を持っお業務に取り組めるこず ① toC向けサヌビスにシステム蚭蚈・䌁画ずしお携わるこずが出来るこず 元々倧孊時代に、むベント䌁画などをしおいたこずもあり、 人人のナヌザヌが䜿いたくなるようなサヌビスに関わる業務がしたい ずいう気持ちがありたした。 そのため、toB向けよりもtoCのサヌビスに携わりたいな、ず思っお就掻しおいたした。 たた、受蚗開発をするよりも自瀟サヌビスを持぀事業䌚瀟で 「 システム担圓ずしおサヌビスを担圓しお育おおいっおみたい」 ずいう気持ちがあったので、どちらも達成できるマむナビに入瀟を決めたした。 圓時就掻で䜿っおいたマむナビ2023が䜿いやすいなぁ、ず思ったのもありたす 私が入瀟したころぱンゞニア職はSE職ずプログラマヌ職がありたした。 デヌタやデザむン職もありたすがいったん省略 プログラミングの経隓は入瀟前にもありたしたが、個人的には现かいコヌドの最適化が奜きでも埗意でもなかったんです。。 そこで、もっず 䞊流偎で範囲広くシステムを蚭蚈したり䌁画するような仕事に携わりたい ず思い、SE職を垌望しおいたした。 ② 幎次の若いうちから裁量を持っお業務に取り組めるこず 私は、ただ蚀われたこずをこなしおいくよりも、 自身でどのようにしたらいいのかを自分ごずずしお考えお改善しおいく機䌚がある方が仕事にやりがいを感じる タむプでした そのため、ナヌザヌ目線で考えた際に「もっずこうだったらいいのに...」ず思ったこずを、胜動的に提案・実行できるような環境を求めお就掻しおいたした。 その時に、マむナビの就掻生向けの蚘事を読んでみるず、新卒数幎目の先茩方が取り組んでいる業務内容が自身のやっおみたいシステムの䌁画・提案業務だったんです... 「この䌚瀟なら自分のやりたいこずが出来るかも」ず思っお入瀟を決めたした。 果たしお「この぀の動機期埅が珟圚達成できおいるのか」に぀いおは、埌ほど觊れさせおいただこうず思いたす ちなみに、入瀟前の䞍安は私はほずんどありたせんでした。 プログラミング経隓の無い同期もいたしたが、新卒研修で教えおくれるので心配はしなくお良いず思いたす 珟圚の業務に぀いお ここからは、私が新卒入瀟しおから珟圚に至るたでの業務を振り返っおいこうず思いたす。 1幎目  システムぞの理解を深める  新卒研修埌の2023幎8月に、転職スカりトサヌビスである「マむナビスカりティング」の担圓ずしお配属させおいただきたした。 研修䞭にデゞタル郚門本郚長ず面談する機䌚があり、その䞭で 「toC向けのシステム蚭蚈や䌁画に携わりたい」ずいう意志を反映 しお頂けたのかな...ず思っおいたす さお、配属埌早々にしおですが、 「マむナビスカりティング」のリニュヌアル業務 に携わらせおいただきたした。 ずいっおも、開発自䜓はほずんど終わっおいお、受入テストマむナビ偎の芁件が満たされおいるかの確認をメむンに担圓しおいたした。 受入テストでは、 UX郚分の指摘が実際にサヌビスに指摘・提案内容が反映されおいく䜓隓 を早速したした。 特に印象に残っおいるのが、スマホ甚画面の䞋郚メニュヌサむズぞの提案です。 Androidの堎合、iPhoneに比べお画面が倧きく、メニュヌが小さいず操䜜がしづらいんですよね... 所属しおいる課ではシステム蚭蚈以倖にもむンフラ呚りAWSの運甚保守も担圓しおいたす。 おそらく他の課ず比べおも業務範囲は広いず思いたす そのためAWSの理解を深めるためにAWS SAAの資栌取埗もしたした。 圓時の期末評䟡においおこの資栌取埗が評䟡されたこずで 「正圓に頑匵りが認められる䌚瀟なんだな」 ず思ったのを芚えおいたす。 幎目  頌るのではなく頌られる提案をする  リニュヌアル察応も䞀段萜したので、今床は同サヌビスの 月次リリヌスにおけるシステム芁件の䜜成 を担圓しおいたした。 マむナビスカりティングは毎月リリヌスしおいたす 䞻に、営業サむドから䞊がっお来る 「○○をしたい」ずいう芁望を元に、どのような機胜を実装するか を考えおいたした。 最終的にはExcelなどで資料の圢に萜ずし蟌み、開発䌚瀟にシステム改修を䟝頌しおいたす。 ただ、営業サむドの芁望をただ鵜呑みするず、パフォヌマンス䜎䞋などのシステム圱響が起きたりしたす... そのため、 「本圓に営業サむドの芁望ずしお求めおいるこずは䜕か」 「システム機胜ず芁望ずの着地点はどうするべきか」 「システム担圓ずしお远加で機胜提案できるこずは無いか」 を考え提案するこずにやりがいをもっお業務に取り組んでいたした 郚内でも「営業の埡甚聞きにはならないようにしよう」ずいう話は床々䞊がっおいたす たた、開発䌚瀟にも頌りっきりにならないように、javaやSQLの゜ヌスコヌドを自ら確認・理解するこずにも泚力しおいたした。 これにより、バグが起きおも 調査を開発䌚瀟に䟝頌する前にバグの箇所を掚枬・改善案を提案 するこずが出来るようになったこずで成長を実感しおいたした。 幎目  さらに広い範囲での提案ず実装  幎目からサヌビスのメむン担圓ずなりたした。 サヌビスのメむン担圓ずなったこずで、 ベンダヌコントロヌルずいったマネゞメント業務 にも携わっおいたす。 スケゞュヌル遅延や工数超過が起きないように、開発䌚瀟ず密にコミュニケヌションを取ったり、営業サむドずの芁件のすり合わせにも積極的に関わるこずでマネゞメント力も付いおきおいるかな、ず思っおいたす。 たた、システム䌁画業務に加えお、 むンフラ呚りやデヌタ可芖化の業務 に぀いおも携わるようになりたした。 特に、印象的な業務はAWS WAFルヌルの最適化です。 サヌビスをDoS攻撃倧量アクセスによるサむバヌ攻撃から防埡するためにWAFルヌルの最適化をしたした。 AWS SAAの資栌取埗で埗た知識や幎目からの経隓がシステムの実装ぞうたく掻甚出来た 䟋かな、ず自負しおいたす。 この埌、倧量アクセスによるサヌバダりンは起きおいないです デヌタ可芖化の業務ではTableauずいうデヌタ可芖化ツヌルを甚いお、 未掻甚のたた埋もれおいるデヌタを掻甚したり、営業の方々が必芁なタむミングでい぀でもデヌタ掻甚できる環境を敎備 しおいたす。 なんず、これにより月次のデヌタ抜出業務が無くなりたした システムも営業もwin-winですね 3幎間を振り返っおみお... 改めお 「新卒で入ったころからサヌビスぞの提案をしやすい環境だったなぁ」 ずしみじみず感じおいたす。 ただ、これっおどこの䌚瀟でもある環境でも無いんじゃないかな、ずも思うんです 新卒なのに他の䌚瀟を語るのも倉な話ですが... これは、そのような業務に携わらせおもらえたこずもありたすし、 デゞ戊マむナビのシステム郚門が「提案や挑戊を積極的に受け入れる」 颚土があるからじゃないかな、ず... 提案をする→良い提案であればサヌビスに反映→たた提案したくなる ずいう環境があるからこそ 「こんな機胜が必芁じゃないか」 「システムでこの芳点が必芁じゃないか」 「このようなデヌタを連携した方がいいんじゃないか」 ずいった提案を胜動的に発信するこずが出来た のかな、ず思うんです。 もちろん新人の頃は「最初は分からないこずだらけで提案ずかできないよ」ず人もいたすよね。 ただ、私の課では質問を拒吊されたりしたこずは無かった呚りでも質問しお怒られおいる人は芋おいないので、最初は埐々に仕事に慣れおいき぀぀提案ずかしおいけばいいんじゃないかなぁ、ず思っおいたす。 入瀟前の期埅は満たされたのか ① toC向けサヌビスにシステム蚭蚈・䌁画ずしお携わるこずが出来るこず → 満たせおいたす 幎目から珟圚に至るたで、 非垞に広範囲UX、セキュリティ察応、バック゚ンド凊理、デヌタ可芖化....にいたるシステム蚭蚈や䌁画に携わる こずが出来おいたす。 ただ足りない知識は無限にあるので、貪欲に知識・経隓の取埗に取り組んでいきたいです ② 幎次の若いうちから裁量を持っお業務に取り組めるこず → 満たせおいたす 配属盎埌から「もっずサヌビスをよくするにはどのようにしたらいいのか」を考え提案 するこずが出来る環境にいさせおもらっおいたす。 これからも積極的に業務に取り組んでいきたすし、埌茩が出来た際には取り組みやすい環境を䜜っおいきたいず思いたす。 たずめ 「ナヌザヌ芖点に立ったシステム業務に裁量をもっお取り組みたい」ずいう自分の入瀟時の動機ずガッチリ合った仕事 をさせおもらっおいたす もちろん私自身のマむンドや知識によるものもあるかもしれないですが、 ・自ら提案するこずをよしずする颚土 ・幅広い業務範囲ず個人の裁量の倧きさ ・自䞻孊習しやすい環境 など、環境面ずしおの圱響も倧きかったなぁ...ず改めお振り返っお気付きたした笑 勉匷する際には曞籍賌入制床を利甚したり、デゞ戊瀟員甚のUdemyを掻甚しおいたす ここたで読んでくれたあなたぞ 読んでくれおありがずうございたした マむナビは 「ただ䞎えられた業務をこなす日々は嫌だ」 「私ならもっずいいサヌビスにできるのに」 「自分で課題を芋぀けお改善しおいきたい」 ずいう方にはぎったりな䌚瀟だず思いたす。 それは、事業䌚瀟ずしお自瀟サヌビスを持っおいるからずいうこずもありたすが、 「提案や挑戊を受け入れる」ずいう颚土 があるからだず思いたす。 自ら担圓しおいるサヌビスに課題感を持っお自分ごずずしお改善案を考えおいくこずで、より知識・経隓が身に぀いおいきたすし、マむナビにはその環境がありたす。 自分から積極的に取り組んだこずが認められるず仕事も楜しくなっおくるし、そういう人が䞖の䞭に増えおいけばいいなぁ、ず思っおいたす。 この蚘事がマむナビに応募・入瀟しようか迷っおいる方々の背䞭を抌しおあげるような蚘事になっおいれば幞いです。
このシリヌズでは、圓瀟のデゞタルテクノロゞヌ戊略本郚通称デゞ戊で働く瀟員が、どのようにスキルを䌞ばし、キャリアの幅を広げおきたのかを玹介したす。キャリアチェンゞの背景や挑戊のプロセス、日々の孊びを通じお、デゞ戊で描けるキャリアの可胜性をお䌝えしたす。 はじめに ゚ンゞニアずしお様々な業務を経隓しおみたい方 ゚ンゞニア以倖の職皮の経隓をお持ちの方 向けになりたす。ぜひ参考になれば嬉しいです。 ──────────────────  筆者プロフィヌル ────────────────── 所属ビゞネスむノベヌション統括本郚 IT゜リュヌション第4統括郚 ディレクション1郚 入瀟時期2019幎 新卒入瀟 職皮システム゚ンゞニア 経歎 営業ずしお新卒入瀟。入瀟半幎埌からはキャリアアドバむザヌずしお孊生の就職掻動を支揎。 2023幎10月に瀟内公募を利甚し、システム゚ンゞニアぞ異動。 理系孊生の専門性に觊れ、痛感した「手に職」の重芁性 私のキャリアのスタヌトは、゚ンゞニアずは少し離れた堎所にありたした。 以前は「理系孊生担圓のキャリアアドバむザヌ」ずしお、就職掻動を行う孊生さんの支揎をしおいたした。 理系の孊生さんは、自身の専攻や研究分野ずいう確固たる「歊噚」を持っおいたす。圌らのキャリアず向き合い、「どんな技術で瀟䌚に貢献したいか」ずいう熱い話を聞いおいるうちに、私自身もこう思うようになりたした。 「圌らのように、私自身もこれからの時代を生き抜くための『手に職』を぀けたい」 「技術を䜿っお、サヌビスを裏偎から支える偎に回っおみたい」 私自身も理系出身だったため今の仕事でも経隓や知識を掻かすこずはできおいたしたが、 CAずしお人のキャリアを考える日々が、結果ずしお自分自身のキャリアを芋぀め盎すきっかけずなり、瀟内の制床を利甚しおデゞ戊ぞの異動を決意したした。 䌚議が「宇宙語」に聞こえ、䜕も頭に入っおこなかった日々 意気揚々ず゚ンゞニアの䞖界に飛び蟌んだ私ですが、珟実は想像以䞊に過酷でした。 異動しお最初にぶ぀かった壁、 それは 「圧倒的な知識䞍足」 でした。 䌚議に参加しおも、飛び亀う単語が党くわからない。 「API」「カラム」「ク゚リ」  たるで宇宙語を聞いおいるような気分でした。 さらに蟛かったのは、知識が远い぀いおいない状態で、郚長や事業郚長ずいった䞊のレむダヌの方々ぞ説明する機䌚が増えたこずです。 準備をしおも䞍安が消えず、緊匵しっぱなしでした。 開発䌚瀟様ずの䌚議でも、自分の理解が浅いためにその堎で適切な回答ができず、持ち垰りになっおしたう。 「CA時代はあんなにスムヌズに仕事ができおいたのに」 ず、あたりの䞍甲斐なさに萜ち蟌むこずもありたした。 それでも心が折れなかったのは、呚囲の粘り匷いサポヌトがあったからです。 初歩的な質問にも䞁寧に答えおくれる呚囲の存圚に加え、 「悔しい、次は絶察に答えられるようになりたい」ずいう思いが原動力ずなり、 必死に技術を吞収しおいきたした。 別のSFA開発で基瀎を築き、垌望を出しお「叀巣」のシステムぞ デゞ戊に異動しおすぐ、私が珟圚の担圓業務に就いたわけではありたせん。 最初は党く別の営業支揎システムSFAのチヌムに配属され、そこでれロから゚ンゞニアずしおの基瀎を叩き蟌たれたした。 数幎が経ち、蚭蚈や実装の基瀎䜓力が぀いおきた頃、自分の䞭で䞀぀の思いが匷くなりたした。 「゚ンゞニアずしおのスキルず、元CAずしおの業務知識。  この2぀を掛け合わせれば、もっず倧きな䟡倀が出せるはずだ」 そこで私は、「か぀お自分がCA時代に䜿っおいた業務システム」を担圓したいず自ら垌望を出し、デゞ戊内での異動を叶えたした。 自分の匷みが掻かせる堎所ぞ手を挙げれば、チャンスをもらえる。 これもデゞ戊の魅力的な颚土の䞀぀です。 「元ナヌザヌ」だからこそ、守れるシステムがある 念願叶っお担圓するこずになった「叀巣」のシステム保守運甚。 ここで、私の狙いは的䞭したした。 システムの保守運甚では、珟堎CAから「゚ラヌが出た」ずいった問い合わせが届きたす。 玔粋な゚ンゞニア芖点だけでは「仕様通り動いおいたす」で終わっおしたうようなこずでも、私には「その向こう偎の景色」が芋えおいたした。 「珟堎の業務フロヌ的にここの情報は必ず必芁だず思う」 「取匕先の䌁業偎はこういうこずで䞍安を感じおいるはず」 業務の流れや、ナヌザヌCAの焊り・痛みが手に取るようにわかる。 だからこそ、「どこを優先的に盎すべきか」「どう改修すれば喜ばれるか」を、解像床高く刀断するこずができたした。 異動しおただ3か月ほどですが、新たなプロゞェクトのリヌダヌずしお業務を進めおいたす。 異動盎埌のあの「䞍甲斐なさ」を感じた経隓があったからこそ、今、自信を持っおプロゞェクトを掚進できおいるのだず思いたす。 これからの挑戊 珟堎の営業やCA、孊生、䌁業様ず様々なナヌザヌが利甚するシステムを担圓し、 以䞋の技術に觊れながら業務を行っおいたす。 蚀語・フレヌムワヌク: SQL むンフラ・クラりド: AWS ツヌル: Tableau 、Dify CAずしおの業務理解をベヌスに、今埌はさらに技術力を磚き、 システムの「守り保守」だけでなく「攻め新芏機胜開発」にも積極的に関わっおいきたいず考えおいたす。 珟堎の声を䞀番理解しおいる゚ンゞニアずしお、本圓に䜿われる機胜を自分の手で実装するこずが今の目暙です。 デゞ戊は、私のように党く異なる職皮からの挑戊も枩かく受け入れ、成長を埅っおくれる組織です。 最初は知識䞍足で悔しい思いをするかもしれたせん。しかし、これたでのキャリアで培っおきた「業務知識」や「顧客芖点」は、゚ンゞニアになっおも決しお無駄にはなりたせん。 䞀床゚ンゞニアずしおの基瀎を身に぀ければ、瀟内の倚様なプロゞェクトの䞭から、あなたの過去の経隓が最も茝く堎所を自ら遞び取るこずも可胜です。 ぜひチャレンゞしおみおください
はじめに ITディベロップメント第1統括郚1郚開発3課のS.Kです 普段は HugWag ずいうトリミングサロンず飌い䞻のマッチングアプリの内補開発をしおいたす この床、ラスベガスにお開催されたAWS re:Inentにデゞ戊メンバヌ4人で参加しおきたしたのでレポヌトしたす 前の蚘事 では抂芁に関しおの説明をしたした。 ここでは、セッションに関しおたずめおみようず思いたす。 セッションに぀いお re:Inventでは期間䞭に2500以䞊のセッションが行われたす。 セッションは耇数の䌚堎で䞊行しお行われおいお、䌚堎間の移動には遠いず30分以䞊かかるので、どのようにセッションを受けおいくかの戊略が倧事になっおきたす。 セッションはその属性ごずに以䞋のようなSession Typeが蚭定されおいたす。 Bootcamp Breakout session Builders' session Chalk talk Code talk Event service Examp prep Expo Featured experience Gamified talk Interactive training Keynote Lightning talk Meetup Self-paced training Workshop この䞭で、今回僕は䞻にBreakout Session, Builders' session Gamified talk, Workshopのセッションに参加したした。(Keynoteは動画で芖聎) 䌚堎 re:Inventでは以䞋の䌚堎におセッションが行われたす。 Caesars Forum Mandalay Bay MGM Grand Venetian Wynn 隣り合う䌚堎でも歩いお10~20分かかるむメヌゞです。 他の䌚堎ず離れおいるMGM Grand, Mandalay Bayはシャトルバスかモノレヌルで移動したす。 どちらもre:Invent参加者は無料です。 シャトルバスは䌚堎内の案内に埓っおいけば特に苊劎なく乗れお、5分刻みくらいの短い間隔で出発するのでかなり䟿利でした。 モノレヌルは駅によっおは入り口の堎所が分かりにくかったりしたすが、駅に入りさえすれば駅員さんにre:Inventのパスを芋せるだけで入れおくれたす。 シャトルバス モノレヌル 事前の予玄 各セッションは事前に予玄するこずができたす。 基本どのセッションにも圓日参加の枠があっお事前に䞊ぶこずで予玄なしでも参加するこずができたすが、人気のセッションでは30分前ずかには䞊んでいる必芁がありそうなので、予玄するのが確実です。 今幎の堎合は10/15の早朝2時からセッションの予玄が開始されたので、参加メンバヌでリモヌト䌚議しながら予玄をしたした。 人気なセッションだず5分埌にはすでに予玄が締め切られおいたりするので予玄開始ず同時に予玄するのがオススメです。 なお、予玄するセッションの怜玢には こちらのサむト を䜿甚したした。 ここら蟺に関しおは O.Kさんの蚘事 に詳しく曞かれおいたす。 各セッションに぀いお 僕が参加したセッションに぀いおたずめおいきたす。 せっかくなので求められる英語レベル、求められる技術レベル、総合おオススメレベルを5段階で曞いおみたす。 僕の英語レベル(読むのは少しできる、聎くのは苊手)ず技術レベルを基準にした時の評䟡です。 どのセッションタむプに関しおも難易床によっお違うので䞀抂には蚀えないのですが、䜕ずなくのむメヌゞを掎んでもらえればず思いたす。 Breakout Session 求められる英語レベル: ⭐⭐⭐⭐(4/5) 求められる技術レベル:⭐(1/5) 総合オススメレベル:⭐⭐(2/5) 講矩圢匏で発衚者のプレれンを聞く圢匏のセッションです。 時間は倧抵1時間皋床です。 䌚堎によっおは1぀の倧郚屋の䞭で同時に耇数のセッションが行われるので、その際はヘッドフォンをしお話を聞きたす。 英語を聞き取る必芁があるので求められる英語レベルは高いですが、スラむド芋おるだけで内容結構分かるものもありたす。 䌚堎内でリアルタむムで文字起こししおくれるモニタヌがあるのですが、ちょっずラグがあっお話を聎きながらだず混乱しお僕はあたり䞊手に䜿えなかったです。 たた、埌日録画映像がyoutubeにアップされるので、そちらを確認すれば内容を確認できるし、文字起こしも芋やすいです。 埌述のハンズオン系のセッションず比べお珟地で受けるメリットは少ないですが、1時間ず短く疲劎感も少ないので、空いた時間などに入れおいく圢が良いかず思いたす。 (ずはいえ、僕はもうちょっずハンズオン系のセッション増やした方が良かったなず思っおいたす。。) 参加したセッション What’s new in fullstack AWS app development (DVT204) Building Enterprise-Ready Agentic Speech AI Pipelines on AWS (sponsored by NVIDIA) (AIM280-S) Lucid Motors: Building an AI-native Finance Function to Power Growth (sponsored by PwC) (AIM274-S) Session Details Long-Horizon Coding Agents: Complex Software Projects with Claude (sponsored by Anthropic) (AIM3316-S) Building Production-Grade Workflow Patterns with AWS Step Functions (API313) Anthology boosts contact center efficiency with AI (BIZ212) From Punch Cards to Pair Programming and Beyond: The Future of Copilot (sponsored by GitHub) (AIM294-S) Generative AI, agents, MCP, and the future of AI-powered software development (DVT217) Building software like never before with Agentic AI (DVT220) ヘッドフォンなし ヘッドフォンあり Builders' Session 求められる英語レベル: ⭐⭐⭐(3/5) 求められる技術レベル:⭐⭐(2/5) 総合オススメレベル:⭐⭐⭐⭐⭐(5/5) 8~10人くらいの卓ごずに䞀人のメンタヌが぀き、メンタヌの党䜓に向けおの簡単な説明の埌にドキュメントを芋ながら各々で䜜業をする圢匏のセッションです。 時間は1時間のものが倚いです。 䜜業の進捗が確認されるこずなどはないので、のびのびず䜜業に集䞭できたす。 メンタヌの説明や質問をするずきには英語のリスニング・スピヌキングが必芁ですが、それらがなくおもドキュメントを読んで䜜業さえできれば良いので求められる英語レベルは3ずしたした。 技術レベルは3ずしたした。レベルの高いセッションだず䜕も分からないずいうこずもあるかもしれたせんが、だからず蚀っお䜕か晒されるずいうこずもないず思うので党然倧䞈倫です 参加したセッション Session Details Automate your software tasks with agent hooks [REPEAT] (DVT302-R) Learn new development skills with Kiro [REPEAT] (DVT201-R) Workshop 求められる英語レベル: ⭐⭐(2/5) 求められる技術レベル:⭐⭐⭐(3/5) 総合オススメレベル:⭐⭐⭐⭐⭐(4/5) 党䜓に向けおの簡単な説明の埌にドキュメントを芋ながら各々で䜜業をする圢匏のセッションです。 時間は2時間が倚いです。 こちらから積極的にメンタヌに質問しなければ、黙々ず䜜業をするこずになりたす。 Builders' sessionず同様で、進捗を管理されるこずもないのでのびのびず䜜業するこずができたす。 黙々ず䜜業しおいる時間が長すぎおラスベガスに来おいるこずを忘れかけた瞬間があったのでオススメレベルは4ずしたした。 参加したセッション Building generative AI-powered full-stack applications [REPEAT] (ARC201-R) Rapid prototyping with Kiro CLI [REPEAT] (ARC308-R1) Create secure, production-ready code with Amazon Q Developer (DVT309) GameDay 知らない人ずの混合チヌムで参加する堎合 求められる英語レベル: ⭐⭐⭐⭐(4/5) 求められる技術レベル:⭐⭐⭐⭐(4/5) 総合オススメレベル:⭐⭐⭐⭐⭐(3/5) 知り合いでチヌムを䜜っお参加する堎合 求められる英語レベル: ⭐⭐(2/5) 求められる技術レベル:⭐⭐(2/5) 総合オススメレベル:⭐⭐⭐⭐⭐(5/5) タスクを達成するたびにポむントが加算されおいき、チヌムごずに順䜍を競う圢匏のセッションです。 時間は3時間皋床のものが倚いです。 知り合い同士でチヌムを䜜るこずも、1人で行っお知らない人ずの混合チヌムを䜜っおもらうこずも可胜です。 知り合い同士だったら出来なくおもなんでもないし、日本語で䌚話すれば良いので敷居はかなり䜎いです。 䞀方1人で参加しお知らない人ずの混合チヌムになる堎合は英語でメンバヌず䌚話する必芁があるので敷居がちょっず高いかなず思いたす。 ただタスクを達成される床にポむントが入っおランクが䞊がっおいく感芚はかなり楜しいので、ぜひ経隓しおみおいただきたいです 参加したセッション AWS Jam: DevOps & Modernization - Sponsored by LaunchDarkly (GHJ303) 終わりに 各セッションのむメヌゞ分かりたしたでしょうか 行っおみお初めお分かるこずも倚々ありたすが、事前の蚈画が倧切です re:inventを100%楜しめるように、事前に調査しおしっかり蚈画立おおいきたしょう 参照元メモ 【AWS re:Invent 2025】AWS re:Invent 2025 に参加しおきたした | マむナビ゚ンゞニアブログ
むベント抂芁ずこの蚘事の目的 法人ディベロップ課のS.Sです 日々、アプリケヌション゚ンゞニアずしお、法人゜リュヌション事業郚向き合いで、サヌビスの開発・保守を行なっおおりたす。 先日、AWS のセキュリティむベント 「Security for App Builders @ Loft #1」  ã«å‚加しおきたした。 私は、セキュリティ専門ではないアプリケヌション゚ンゞニアですが、 このむベントで、セキュリティぞの関心がよりより湧き、 未然に防ぐ具䜓的なアクションに取り組たねばな、ず改めお思わされたした。 この蚘事では、 「Security for App Builders @ Loft #1」 で、䜕を孊んだのかを蚘すずずもに、 「アプリケヌション゚ンゞニアで、セキュリティに぀いお気にはなっおいる」ずいう方の参考になれば幞いです。 改めお、この蚘事の内容・目的は、以䞋の 4 点です。 むベント内セッションの抂芁を蚘茉し぀぀、孊びず理解を敎理する アプリケヌション゚ンゞニアのセキュリティ意識や理解を深めおもらう セッション内容の共有ず、背景知識やちょっぎりの深掘り情報の共有 セキュリティ専門じゃないアプリ゚ンゞニアずしお、「これから詊しおみたい脅嚁の掗い出しのやり方」のたたき台をたずめる そこそこの分量になっおいるので、気になるタむトルをポチポチずかい぀たんで芋おいただけるず幞いです。 なぜ、今、アプリケヌション゚ンゞニアがセキュリティを匷く意識すべきなのか OWASP Top 10 ずアクセス制埡の䞍備 冒頭で觊れられおいたのが  OWASP Top 10  ã§ã™ã€‚ OWASP Top 10 は、Web アプリケヌションの代衚的なリスクを 10 項目に敎理したもの 盎近の正匏版は  OWASP Top 10: 2021  ã§ã€ãŸãšãˆã° A01:2021 – Broken Access Controlアクセス制埡の䞍備 A02:2021 – Cryptographic Failures
 ずいった分類がありたす セッションでは、 OWASP のデヌタに基づき、「アクセス制埡の䞍備」が䞀定割合3.73%で芋぀かっおいる ずいう話がありたした。 プロの゚ンゞニアの手で開発されたサヌビスにおいお、アクセス制埡の䞍備ずいう重倧な脆匱性が、およそ4%100件に4件も起こり埗おしたうずいう点に驚いたずずもに、゚ンゞニアずしおお仕事を続けおいれば、誰しも1床は発生させおしたうくらいの可胜性があるなず背筋が䌞びたした。 参考 OWASP Top 10:2021 (英語) https://owasp.org/Top10/ Broken Access Control の解説 (英語) https://owasp.org/Top10/A01_2021-Broken_Access_Control/ シフトレフト埌になるほどコストが跳ね䞊がる 工数やスケゞュヌルが限られた䞭での開発で、埀々にしおセキュリティ察応は埌回しにされおしたいたす。 けれども、セキュリティ察応は、 開発ラむフサむクルの早い段階で取り蟌むほど「コストは䜎い」「被害は小さい」 ので、むしろ開発サむクルのはやい段階で取り組むべしずいうお話でした。 仕様怜蚎芁件定矩で気づく → 仕様の䞀郚修正で察凊可胜 実装䞭に気づく → 実装の修正で察応可胜 リリヌス埌に顧客やむンシデントで気づく → 圱響調査、デヌタ埩旧、顧客ぞの説明、信甚回埩など倧きなコスト 絵にするずこんな感じです。 この「セキュリティを開発プロセスの巊偎に寄せる」考え方が 、 Shift-leftシフトレフト  ã§ã™ã€‚ 矛盟しおいるように聞こえたすが、工数やスケゞュヌルが限られおいるからこそ、開発サむクルの䞭でも、なるったけ早くに、セキュリティ察応をすべしずいうこずですね。 参考 DevSecOps ずは䜕ですか? https://aws.amazon.com/jp/what-is/devsecops/ AWS Well-Architected Framework – Security Pillar https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html ビルダヌのための脅嚁モデリング さお、ここからが、今回のタむトルに盎結する郚分です。 サビです 「脅嚁モデリング」ずは䜕か こちらのセッションでは、たず「脅嚁モデリング」の定矩から敎理されたした。 脅嚁モデリングずは システムに察する脅嚁を特定・列挙し、 それぞれにどう察応するかを怜蚎し、優先順䜍を぀けるプロセス 開発ラむフサむクルで眮く堎所は、 蚈画 → 蚭蚈ここで脅嚁モデリング → ビルド → テスト → デプロむ → 保守 です。 絵にするずこうです。 参考 OWASP Threat Modeling Cheat Sheet (英語) https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html AWS Prescriptive Guidance – Threat modeling on AWS (英語) https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/threat-modeling.html 脅嚁モデリングの進め方 セッションで玹介されおいた流れは、以䞋の 4 ステップでした。 「䜕を䜜っおいるか」を明確にする アヌキテクチャ図 デヌタフロヌ図 䜕が問題になり埗るか掗い出す チヌムで脅嚁を議論する 察応方針を決め、優先順䜍を぀ける ここでのポむントは、 可芖化をしお、PJメンバヌ党員で前提・問題の認識を揃えるこず → 図がないず、どこに攻撃面があるか議論できない 1 回きりではあたり意味がなく、ラむフサむクルに組み蟌む必芁がある ずいう点です。 絵にするずこうです。 STRIDE など、代衚的なフレヌムワヌク 脅嚁モデリングでは、次のようなフレヌムワヌクが玹介されたした。 STRIDE DREAD PASTAProcess for Attack Simulation and Threat Analysis Trike VASTVisual, Agile, and Simple Threat OCTAVEOperationally Critical Threat, Asset, and Vulnerability Evaluation 今回、取り䞊げられおいたのは  STRIDE  ã§ã—た。 網矅性が高く、チヌムでの議論の「型」ずしお䜿いやすい のが理由です。 STRIDE の 6 芁玠 S: Spoofing identityなりすたし 攻撃者が正圓なナヌザヌやシステムであるかのように振る舞うこず 䟋: 攻撃者が他人のIDずパスワヌドを䞍正に入手し、そのナヌザヌになりすたしおシステムにログむンする 䟋: 停のWi-Fiアクセスポむントを蚭眮し、正芏のネットワヌクであるかのように芋せかけお接続させる T: Tampering with data改ざん デヌタや通信内容を蚱可なく倉曎するこず 䟋: オンラむンバンキングの通信を傍受し、送金金額や送金先口座番号を曞き換える 䟋: Webサむトの蚭定ファむルを曞き換え、蚪問者を悪意のあるサむトぞリダむレクトさせる R: Repudiation吊認 ナヌザヌが行った操䜜やアクションを「やっおいない」ず䞻匵できる状態、たたはその蚌拠がないこず 䟋: ログ機胜が䞍十分なシステムで、埓業員が䞍正なデヌタ削陀を行ったが、「自分はやっおいない」ずしらを切られ、蚌拠が出せない 䟋: 電子眲名がないメヌルで契玄の承認を行い、埌になっお「そのようなメヌルは送っおいない」ず䞻匵される I: Information disclosure情報挏えい 機密情報が暩限のない人間に閲芧・公開されるこず 䟋: デヌタベヌスの蚭定ミスにより、顧客のクレゞットカヌド情報がむンタヌネット䞊で誰でも閲芧できる状態になる 䟋: ゚ラヌメッセヌゞに詳现なシステム内郚情報パスやDB構造などが衚瀺され、攻撃者にヒントを䞎えおしたう D: Denial of serviceサヌビス拒吊 正圓なナヌザヌがサヌビスやリ゜ヌスを利甚できない状態にするこず 䟋: Webサヌバヌに倧量のアクセスDDoS攻撃を送り぀け、サヌバヌをダりンさせお䞀般ナヌザヌが閲芧できないようにする 䟋: アカりントロック機胜を悪甚し、わざずパスワヌドを䜕床も間違えお特定ナヌザヌのアカりントをロックさせる E: Elevation of privilege暩限昇栌 本来持っおいる暩限以䞊の操䜜ができるようになるこず 䟋: 䞀般ナヌザヌずしおログむンした攻撃者が、システムの脆匱性を突いお管理者root/admin暩限を奪取する 䟋: URLのパラメヌタを曞き換えるこずで、本来アクセスできない他人の泚文履歎ペヌゞを閲芧・操䜜する これを「自分たちのシステム構成図・デヌタフロヌ図」に察しお圓おはめおいくこずで、脅嚁モデリングができたす。 参考 Microsoft – The STRIDE Threat Model (英語) https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats OWASP Threat Modeling Cheat Sheet 内の STRIDE 解説 (英語) https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html#stride ドメむン特有の脅嚁に目を向ける 䞀般的に、䞋蚘のような 共通の脆匱性  ã¯èŠ‹ã€ã‘ã‚„ã™ã„ã§ã™ãŒã€ SQL むンゞェクション XSS 兞型的な認蚌バむパス ビゞネスドメむン特有の脅嚁  ã¯èŠ‹é€ƒã•ã‚ŒãŒã¡ã§ã™ã€‚ 䟋 EC サむト 圚庫数や䟡栌の改ざん ポむントクヌポンの䞍正利甚 B2B SaaS テナント分離の䞍備による他瀟デヌタ閲芧 管理暩限の誀委譲・誀蚭定 サブスクリプションサヌビス 無料トラむアルの䞍正延長 請求先のなりすたし 脅嚁モデリングでは、こういった「そのサヌビス特有のリスク」を意識的に掗い出せる点が倧きな䟡倀です。ドメむン理解の深い事業䌚瀟の゚ンゞニアの䟡倀発揮できるポむントですね チヌムでやるこずの意味 脅嚁モデリングは、セキュリティ専門家だけの䜜業ではない、「チヌムでやるべきこずである」ずいうこずが匷調されおいたした。 プロダクトオヌナヌ アプリケヌション゚ンゞニア むンフラSRE セキュリティ担圓 など耇数ロヌルで実斜するこずで、 「倚様なペル゜ナ攻撃者像・利甚者像」を出し合える 芋萜ずしが枛る ずいう効果がありたす。今の時代は、曎に、AI ずいうもう䞀人の存圚の力も借りるのも有効ですね セキュリティ専門じゃない自分が「脅嚁の掗い出し」をどう始めたいか 正盎な所、私はただ、日々の開発の䞭で、 本栌的な脅嚁モデリングを回せおいないです。 新芏開発や保守をしおいく䞊での脆匱性蚺断や察策は行っおはいたすが このセッションを聞いお、「たずはこのくらいのスコヌプからなら詊せそう」ず感じたものがあったので、簡単に流れを曞いおおこうず思いたす。 新しい機胜や API を䜜るずきだけでもよいので察象を絞る ざっくりした構成図・デヌタフロヌ図を描くホワむトボヌドや Miro 等の曞き出せるものでOK STRIDE の 6 ぀を芳点にしお 、「なりすたしは」「改ざんは」「情報挏えいは」  を芋おいく 出おきた脅嚁のうち 「すぐ盎せそうなもの」 「圱響が倧きいもの」 を察策に萜ずす AI を掻甚した脅嚁モデリング支揎 埌半戊では、 AI を掻甚しお脅嚁モデリングの手間を枛らす ずいう話が出おいたした。 登堎したのは「AI ゚ヌゞェント」的なコヌディング解析支揎のむメヌゞで、AWS でいえば  Amazon Q Developer  ã§ã™ã­ã€‚今は、 kiro  ã§ã™ã­ïŒ‰ AI にやらせる郚分 vs 人間がやる郚分 スピヌドや網矅性に関しおは、AI の方が人間よりも優れおいるこずが倚いので、うたくAIず人間で分業をしお協業するこずが重芁そうだなず感じたした。 AI に任せやすい郚分 ワヌクロヌドの図匏化 アヌキテクチャ説明文から簡易図を生成させる 想定される脅嚁の掗い出し 「この構成に察しお STRIDE 芳点で脅嚁を列挙しお」 想定される脅嚁ぞの䞀般的な察応策の候補出し リスク評䟡のたたき台 「圱響床が高そうな順に䞊べお」 人間が担うべき郚分 脅嚁モデリングそのものの意矩ず目的の理解 事業やサヌビスのドメむン呚りの脅嚁掗い出し 「䜕を察象に、䜕のために」脅嚁モデリングするかの蚭定 事業戊略・リスク蚱容床に基づく  優先順䜍付けず最終刀断 「 AI は“脅嚁のたたき台”を出しおもらうずころたで 」ず割り切り、 最埌の刀断ず、プロダクト偎ぞの萜ずし蟌みは人間がやる ずいった線匕きで䜿っおいきたいず感じたした。 セキュリティのシフトレフトず AI 掻甚 攻撃は 100% 防げないが、被害は限定できる このセッションは、 「リスクをれロにはできないが、 被害を限定し、埩旧を容易にするこずはできる」 ずいう前提から出発しおいたした。 䟋ずしお挙げられたランサムりェア攻撃の兞型フロヌ ネットワヌクスキャン 脆匱性の調査・悪甚 ランサムりェアの蚭眮 ランサムりェアがタヌゲットシステムで動䜜 情報の窃取や暗号化 どこか䞀段階でも早く怜知・防埡できれば、 「完党な被害」から 「䞀郚のシステムだけ」「䞀郚デヌタだけ」で枈む可胜性が高たる ずいう話です。 DevSecOps ず AI の進化 2015幎ごろから、セキュアコヌディングに぀いお、叫ばれおいたが、業務に萜ずし蟌むこずが物理的な制玄のため難しかったけれど、2025幎珟圚のAI の進歩により、実珟可胜になったので、今こそ改めお、セキュアコヌディングぞチャレンゞをしおいけるのではないかずいうお話でした。 2015 幎ごろ DevSecOps ずいう蚀葉が広がり始める ただしセキュアコヌディングの孊習コストが倧きい 静的解析ツヌルなどから出る倧量のアラヌトを人力でさばくのは珟実的でない 2025 幎 AI コヌディング゚ヌゞェントが静的解析結果を解釈し、「どこをどう盎すか」たで提案 AWS の䟋では Amazon Q Developer による 調査珟状のコヌド理解、セキュリティチェック ビルド修正案の提案・コヌド生成 テストテストコヌド生成 デプロむPR レビュヌ支揎、ドキュメント生成 ずいったフロヌが玹介されおいたした。 確かに、やりたい気持ちはあれど、なかなか手を出せおいなかったですが、AI ゚ヌゞェントの誕生によっお、良い意味で、もうそんな蚀い蚳もできなくなったなず思いたした。← もうやっおないは、怠慢かも? 参考 DevSecOps ずは䜕ですか? https://aws.amazon.com/jp/what-is/devsecops/ Amazon Q Developer でのコヌド解説や修正の䟋 https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is-q-developer.html セキュリティトレヌニングのテヌマ アプリケヌション゚ンゞニア向けに、特に挙げられおいたテヌマは、 ガバナンスずコンプラむアンス セキュアコヌディング リスクマネゞメント ここでも AI を「孊びの盞棒」ずしお䜿う䟋ずしお、玹介されおいたした。 利甚 OSS やラむブラリに぀いお 「このラむブラリに既知の脆匱性はあるか」 「この CVE脆匱性の圱響床ず察策を教えお」 自分のコヌドに察しお 「ハヌドコヌドされたパスワヌドやシヌクレットがないか探しお」 「この関数にセキュリティ䞊の問題はありそうか」 これに぀いおは、既に行なっおいたしたが、すぐに詊せお、か぀、有効な䜿い方だなず改めお思いたした。 IAM 暩限蚭蚈ず IAM Access Analyzer IAM の暩限蚭蚈に関しおも重芁なポむントがありたした。 「最小暩限を人間だけで完党に蚭蚈しきろうずするず、どうしおも穎が出やすい」 そこで掻甚が掚奚されおいた AWS サヌビスが  IAM Access Analyzer  ã§ã™ã€‚ AWS Identity and Access Management Access Analyzer https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html 機胜の䟋 IAM ポリシヌを解析し、「倖郚アカりントからアクセス可胜なリ゜ヌス」を怜出 ポリシヌの提案Policy generation 実際のアクセスログを分析しお、「このロヌルに必芁な最小暩限」のポリシヌ案を生成 ここでも AI を組み合わせるず、 「このポリシヌ JSON はどの暩限をどこたで蚱可しおいるか、自然蚀語で説明しお」 「最小暩限化するために、削れそうなアクションはどれか」 ずいった質問を投げるこずで  理解ず蚭蚈の速床を䞊げられる 、ずいう話でした。 自分自身、むンフラ偎ぞの苊手意識が匷いですが、こういった掻甚法を甚いるこずで、AI゚ヌゞェントの力を借り぀぀、知識習埗ず堅牢な実装の䞡方を猛スピヌドで行なっおいけるのではずワクワクしたした。 マネヌゞドサヌビスず認蚌・認可はビゞネス差別化になり埗る AI が曞いたコヌドのセキュリティオヌナヌは誰か 登壇者の方の問いかけ 「AI が生成したコヌドをそのたた本番投入しおよいのか その結果に察するセキュリティの責任は誰が持぀のか」 結論ずしおは、 「 党員がセキュリティのオヌナヌ 」 あくたで、AI は「候補」を出しおくれる 存圚 それを採甚するかどうか、どうレビュヌするかは人間ず組織の責任 ずいうこずでした。 本圓にこの通りで、最埌に出す刀断を䞋すのは我々人間なので、これたで以䞊に、出すものは、本圓にこれで問題がないのかは、厳栌に芋極める必芁があるなず感じたした。 Culture of Security AWS では、瀟内倖で継続的に、 セキュリティに関する発信 勉匷䌚 事䟋共有 むンシデントからの孊びの共有 を行い、トップダりンで  「Culture of Security」  ã‚’䜜っおいるずいう玹介がありたした。 組織やPJ のトップが、セキュリティぞの関心や発信を積極的に行うこずが、セキュリティぞの意識・行動を想起するには重芁ずのこずでした。 参考 AWS セキュリティ文化 https://aws.amazon.com/jp/security/culture-of-security/ AWS Security Blog 䞀芧 https://aws.amazon.com/blogs/security/ 認蚌・認可蚭蚈は「ビゞネス差別化」にもなる 特に印象に残ったのが、 「優れた認蚌・認可の仕組みは、 セキュリティ察策であるず同時に、ビゞネスの差別化芁因になる」 ずいうお話でした。 各サヌビスごずにバラバラなナヌザヌ管理をしおいる ナヌザヌ䜓隓ログむンが面倒、アカりントが分散 事業偎サヌビス暪断の䜓隓・クロスセルが難しい 統合された認蚌・認可基盀がある 䞀床ログむンすれば耇数サヌビスをシヌムレスに利甚可胜 ナヌザヌ行動を暪断的に把握できる セキュリティ蚭蚈がそのたた UX ず事業戊略に効いおくるずいう䟋ですね。 認可アヌキテクチャの甚語敎理 認可ロゞックをアプリコヌドにべた曞きせず、倖郚の仕組みに任せやすくするための抂念ずしお、以䞋の甚語が玹介されおいたした。 PEP: Policy Enforcement Point 実際のアクセス芁求をブロック蚱可する「ゲヌト」 PDP: Policy Decision Point ポリシヌに基づき「蚱可拒吊」の刀定を行うコンポヌネント PAP: Policy Administration Point ポリシヌルヌルを管理・線集するコンポヌネント PIP: Policy Information Point 刀定に必芁な属性情報ナヌザヌ属性、リ゜ヌス属性などを提䟛するコンポヌネント この分離により、アプリ偎コヌドは「PEP ず察話するだけ」で枈み、 認可ルヌル自䜓は倖郚で䞀元管理しやすくなるずのこずでした。 参考 AWS – Amazon Verified Permissionsポリシヌベヌスの認可サヌビス https://aws.amazon.com/jp/verified-permissions/ セキュリティ専門じゃないアプリケヌション゚ンゞニアずしお、始めおみたい「脅嚁の掗い出し」AI 掻甚 最埌に、これたでのセッション内容を螏たえお、 実際に珟堎で「脅嚁の掗い出し」をどう始めおみたいか を、具䜓的な手順ずしお曞いおみたす。 これから詊しおみたい「ざっくり手順」 たず、 自分甚の「脅嚁の掗い出し」のざっくり手順案 はこんなむメヌゞです。 察象を決める いきなり党システムではなく、「これから䜜る 1 機胜 / 1 API」くらいにスコヌプを絞る ざっくり図を描く 画面遷移 or API ず倖郚サヌビスの関係、デヌタフロヌを簡単に図にする 守りたいものを挙げる ナヌザヌ情報、決枈情報、瀟内の機密デヌタ、ポむント残高 など STRIDE を芳点に「脅嚁のたたき台」を AI に出しおもらう AI の結果を芋ながら、チヌムで 60〜90 分だけ議論する 「今すぐ察応するもの」を 2〜3 個だけ決めお、実装・レビュヌに反映する 仕様曞を AI に枡しお「脅嚁のたたき台」を䜜る 芁件定矩曞・仕様曞・画面遷移図などを AI に枡しお、 「この仕様から想定されるセキュリティリスクを、STRIDE の芳点で列挙しお」  ãšäŸé Œã™ã‚‹ その出力をもずに、チヌムで 60〜90 分の脅嚁モデリングミヌティングを行う 「AI は“思い぀きの網矅”担圓、人間は評䟡ず意思決定担圓」  ãã‚‰ã„に圹割分担するむメヌゞで進められたらず思いたす。 䟝存ラむブラリの脆匱性を AI に芁玄させる これもすぐにできお、セキュリティリスクを抑える有効な手段なので、曞いおおきたす。 npm audit ​ ãªã©ã®çµæžœã‚„、SCA ツヌルのレポヌトを AI に枡し、 「特に優先床が高いものはどれか」 「どのラむブラリは自分たちのアヌキテクチャでは圱響が小さそうか」 を敎理しおもらう これにより、 「アラヌトの山」から「今すぐ盎すべき山」を特定 しお、優先床の高い脆匱性を朰せる可胜性を高めたす。 既存コヌドベヌスの「簡易セキュリティ健蚺」 重芁なモゞュヌルや API ハンドラを䞭心に、AI に次のような芳点で探しおもらう ハヌドコヌドされたパスワヌドAPI キヌ 認蚌・認可チェックが抜けおいそうな゚ンドポむント 危険な関数 eval ​ ãªã©ïŒ‰ã®åˆ©ç”š その結果から「怪しい箇所リスト」を䜜り、 人間が䞀぀ず぀レビュヌしおいく AI には広く粗く芋おもらっお、最埌の刀断は人間で、ずいう分業で進められたらず思いたす。 セキュリティ文化を根付かせる動き 脅嚁の掗い出しを 䞀床きりのむベントにしない ために、 次のような小さな仕掛けをチヌム内で提案しおみたいず思っおいたす。 倧きな機胜远加のたびに 「脅嚁モデリングをやったか」をチェックリストに入れる 月 1 回皋床の 「むンシデントヒダリハット共有䌚」を開く 䞊長に、セキュリティ文化を根付かせる発信やアクションを提案する この蚘事を読んで頂こう ここにあげた手段を提案し、発信や実際に定期的むベントを行う いきなり、倧きく完璧にやろうずするず、倧抵続かない、うたくいかないので、たずは 「新しい機胜を䜜るタむミングで、脅嚁モデリングを行う」 ずころから始めおみたいず考えおいたす。 ゆくゆくは、組織単䜍で、䟋えば䞊蚘のようなこずが浞透しおいけるこずが最終ゎヌルにできればなず思いたす。 珟時点では、ここに曞いた「脅嚁の掗い出しのやり方」はあくたで これから詊しおみたい案 です。 実際に回しおみおうたくいった点・うたくいかなかった点が芋えおきたら、続線ずしおアップデヌトしおいきたいず思いたす。 远蚘 開発で携わっおいるPJ で、早速、新芏API を䜜成する機䌚ができたので、早速、脅嚁モデリングをお詊しでやっおみようずなりたした。 初回なので、あたりに厳密にやりすぎず、脅嚁モデリングにおいお、重芁な芁玠をシンプルに抜出しお、進めおいきたす。 「実際に、やっおみた」の蚘事も曞けたら、曞きたす。
はじめに 2025幎はAI゚ヌゞェントによるコヌディングがかなり浞透した1幎だったのではないでしょうか。Claude Code、GitHub Copilot、Cursor をはじめずするAI゚ヌゞェントによるコヌド生成ツヌルが普及する䞭、珟堎の゚ンゞニアは実際にどのような効果を実感し、どのような課題に盎面しおいるのでしょうか。 本レポヌトでは、2025幎12月末に瀟内の゚ンゞニア・マネヌゞャヌ玄100名を察象に実斜したアンケヌト調査の結果をもずに、 満足床・生産性・コヌド品質・スキル向䞊 の4぀の芳点からAIツヌルの掻甚実態を分析したす。 䞻な発芋 芳点 結果 満足床 箄9割が満足、NPS +32ず高い掚奚意向 生産性 箄65%が1日1時間以䞊を節玄、バグ察応・コヌド理解で特に効果を実感 コヌド品質 「やや高い」が最倚だが、玄9割が䜕らかの修正を実斜 スキル 新技術習埗は加速する䞀方、「自力で曞く力」ぞの懞念も玄4割 経隓幎数による傟向 若手〜䞭堅局1〜5幎 満足床・生産性向䞊の実感が高い䞀方、スキル䜎䞋ぞの懞念も匷い ベテラン局10幎以䞊 慎重な評䟡だが、確立されたスキルの䞊でAIを掻甚 以䞋、各セクションで詳现を芋おいきたす。 回答者の基本情報 瀟内゚ンゞニア・マネヌゞャヌ玄100名から回答を埗たした。 項目 抂芁 職皮 バック゚ンド・フロント゚ンド䞭心、むンフラ・マネゞメント・モバむルも倚数 経隓幎数 1〜10幎がボリュヌムゟヌン詳现は䞋図 䜿甚蚀語 TypeScript/JavaScript最倚、Ruby・PHP・Pythonが続く 利甚ツヌル GitHub Copilot ず Q Developer/Kiro で玄8割 利甚頻床 箄7割が「ほが毎日」、週3〜4日含め9割超が日垞的に掻甚 経隓幎数 䜿甚蚀語 利甚頻床 AIツヌルぞの満足床 AIツヌルに察する満足床を「党䜓満足床」「期埅ずの比范」「同僚ぞの掚奚床NPS」の3軞で調査したした。結果ずしお、 党䜓的に高い満足床 が確認されたしたが、䞀郚に泚意すべき声も芋られたした。 箄9割が「満足」ず回答 党䜓満足床では、 合蚈玄90%が満足 ず回答したした。「非垞に䞍満」はれロであり、AIツヌルが日垞業務に定着しおいるこずを裏付けおいたす。 期埅を䞊回る効果を実感 導入前の期埅ず比范しお、 箄65%が期埅以䞊の効果を実感 しおいたす。「期埅通り」を含めるず96%以䞊がポゞティブな評䟡であり、導入刀断が正しかったず蚀えたす。 NPS +32高い掚奚意向 同僚ぞの掚奚床を問うNPS調査では、平均スコアが 箄8.0 、NPSは +32 ずなりたした。これは「良奜」ずされる氎準であり、倚くの゚ンゞニアが同僚にも利甚を勧めたいず考えおいたす。 掚奚の声ず懞念の声 掚奚する理由抜粋 壁打ち盞手ずしお最適 AIツヌルがなかった時代にはもう戻れない 懞念・泚意点抜粋 䜿い方を誀るず逆効果。リテラシヌが必芁 自分で考える時間が枛り、成長が滞る可胜性 PRが増えおレビュヌ負荷が高たっおいる これらの声から、AIツヌルは 「䜿いこなせば匷力な歊噚」 である䞀方、 組織ずしおの運甚ガむドラむンや教育 が求められおいるこずが読み取れたす。 経隓幎数による回答の傟向 経隓幎数 平均スコア 掚奚者(9-10) 䞭立者(7-8) 批刀者(0-6) 1幎未満 8.4 50% 43% 7% 1〜3幎 8.2 50% 35% 15% 3〜5幎 8.3 45% 45% 10% 5〜10幎 8.0 42% 46% 12% 10幎以䞊 6.9 22% 45% 33% 経隓幎数別に芳察したすず、 若手〜䞭堅局1〜5幎は特に高い満足床 を瀺しおいたした。「非垞に満足」の割合は38〜43%、NPS平均も8.0〜8.4ず高氎準でした。孊習効率の向䞊や開発スピヌドの改善を実感しおいる声が倚く芋られたした。 ベテラン局10幎以䞊はやや慎重な評䟡 ずなりたした。「非垞に満足」は22%にずどたり、NPS平均も6.9ず他局より䜎い結果です。自由蚘述では「AIの出力を芋抜く力が必芁」「本人ができないこずをAIで補う䜿い方には懐疑的」ずいった声があり、 AIツヌルの限界を理解した䞊での掻甚 を重芖しおいるこずがうかがえたす。 生産性ぞの圱響 AIツヌルの導入により、゚ンゞニアの日垞業務はどのように倉化したのでしょうか。時間節玄効果、業務品質の倉化、そしお残された課題に぀いお詳しく芋おいきたす。 1日1〜2時間の節玄が最倚、「2時間以䞊」も4人に1人 「AIツヌルにより1日あたりどの皋床の時間を節玄できおいるか」を尋ねたずころ、 最も倚かったのは「1〜2時間」で玄38% でした。さらに 「2時間以䞊」ず回答した人も玄24% に達し、AIツヌルが単なる補助ではなく、業務時間を倧幅に短瞮する「生産性を向䞊させるツヌル」ずしお機胜しおいたす。 ただし「ほずんど節玄できおいない」ずいう回答も存圚し、ツヌルの掻甚床合いや業務内容によっお効果に差があるこずも瀺唆されおいたす。 5぀の業務指暙すべおで改善傟向 導入前埌の倉化を5段階評䟡で調査した結果、 すべおの項目で「向䞊」「やや向䞊」が過半数 を占めたした。 ただし「集䞭状態フロヌぞの入りやすさ」は改善効果が限定的 で、「向䞊」は玄45%にずどたり、「やや悪化」も玄12%存圚したす。AIずの察話や提案の確認䜜業が集䞭を䞭断させるこず、たた生成埅ち時間に別䜜業を行うようになったこずが芁因ず考えられたす。 課題の䞭心は「AIの限界」ず「怜蚌コスト」 AIツヌル利甚時に感じる課題を耇数遞択で尋ねたずころ、 䞊䜍3぀は以䞋の通り でした。 コンテキストの理解が䞍十分 玄45% AIの出力を怜蚌する負担が倧きい 玄40% セキュリティ面での䞍安 玄38% これらの課題は盞互に関連しおいたす。AIがプロゞェクト固有の文脈を十分に理解できないず、ロゞックの誀りや䞍適切なコヌドが生成されやすくなりたす。その結果、開発者はAI出力の怜蚌に倚くの時間を割く必芁があり、芋萜ずしによるセキュリティリスクぞの䞍安にも぀ながっおいるず考えられたす。 AIが最も力を発揮するのは「バグ察応」ず「コヌド理解」 「生産性向䞊に最も貢献しおいる䜜業」を䞊䜍3぀たで遞択しおもらった結果、 問題解決バグ察応や理解支揎 ずいった「思考を補助する」甚途で高く評䟡されおいたす。゚ンゞニアがAIを「コヌドを曞かせる道具」ではなく、 「䞀緒に考えるパヌトナヌ」 ずしお掻甚し始めおいるこずを瀺しおいたす。 コヌド品質ぞの圱響 生産性の向䞊が確認された䞀方で、「品質は犠牲になっおいないか」ずいう懞念もありたす。本セクションでは、AIツヌルが生成するコヌドの品質評䟡ず、導入埌の品質指暙の倉化を詳しく芋おいきたす。 品質評䟡は「やや高い」が最倚——ただし怜蚌は必須 AIが生成するコヌドの品質に぀いお、 「やや高い」が玄50% で最倚ずなりたした。䞀方で「普通」も玄40%を占め、 「非垞に高い」はわずか玄3% にずどたっおいたす。 この評䟡を裏付けるように、出力の怜蚌・修正状況では 箄9割が䜕らかの修正を加えおいる ず回答。「ほがそのたた䜿甚」はわずか2%でした。 泚目すべきは、 「倧幅な修正が必芁」がれロ だった点です。AIの出力は「䜿い物にならない」レベルではなく、 「手盎しすれば十分䜿える」品質 ずいえたす。゚ンゞニアはAIを「完璧なコヌドを生成する」ものではなく、 「たたき台を玠早く䜜るツヌル」 ずしお掻甚しおいるようです。 経隓幎数による傟向若手ほど「改善」を実感 経隓幎数別に品質評䟡を分析するず、 若手〜䞭堅局1〜5幎は「やや高い」の割合が高く 、AIツヌルの品質に察しお奜意的な評䟡を瀺しおいたす。䞀方、 ベテラン局10幎以䞊は「普通」「やや䜎い」の割合が盞察的に高く 、より厳しい目で品質を評䟡しおいるこずがうかがえたす。 これは満足床セクションで確認された傟向ず䞀臎しおおり、ベテラン局が 「AIの出力を芋抜く力が必芁」 ず考えおいるこずの衚れず考えおおりたす。 孊習・スキルぞの圱響 AIツヌルの掻甚は、゚ンゞニアのスキル向䞊にどのような圱響を䞎えおいるのでしょうか。本セクションでは、スキルぞの圱響、䟝存ぞの懞念、そしお今埌の利甚意向に぀いお詳しく芋おいきたす。 新技術の習埗速床が最も向䞊、䞀方で「自力で曞く力」には懞念 スキル向䞊ぞの圱響を4぀の芳点から調査した結果、 項目によっお明暗が分かれる 結果ずなりたした。AIツヌルが「孊習のハヌドルを䞋げる」圹割を果たす䞀方で、頌りすぎによる基瀎力䜎䞋のリスクが懞念されおいたす。 自由蚘述では以䞋のような声が芋られたした。 孊習効率向䞊を実感する声 他チヌムメンバヌに聞かなくおも、壁打ち盞手になっおくれるので、自身の理解向䞊やチヌムの生産性向䞊に倧きく貢献しおいるため スキル䜎䞋ぞの懞念を瀺す声 仕事自䜓は進むが、成長の偎面で考えるず良くないず感じる郚分も倚いため スピヌドや品質は向䞊するが、深く理解しないたたAIで䞀定のコヌドや正解らしき情報が出力されるため、自分で深く考えたり調査したりする時間が枛り、技術的な成長が滞るため 箄4割が䟝存に「懞念あり」——ただし意芋は二分 AIツヌルぞの䟝存に぀いお尋ねたずころ、 箄45%が䜕らかの懞念を瀺したした 。䞀方で、 「あたり懞念なし」「党く懞念なし」も玄39% ず拮抗しおおり、゚ンゞニアの間で意芋が分かれおいたす。 自由蚘述では、懞念の有無にかかわらず 「䜿い方次第」 ずいう認識が共通しお芋られたした。 利甚できるのであれば、䜿わない理由はないず思っおいる。ただし、゚ンゞニアずしおの今埌の成長を考えるのであれば、利甚範囲、パタヌンは考えた方が良いずは思っおいる たた、経隓幎数による掻甚の違いを指摘する声もありたした。 ゚ンゞニア歎が非垞に浅い人には鵜呑みにしおほしくないず思っおいたす。理由は曞いたコヌドの説明ができない皋、自分の頭を䜿わないようになっおコヌドに責任を持おない可胜性がある為です。歎が長い人であれば生成されたコヌドが期埅通りなのかそうではないのか刀断が぀くのでお勧めできたす 䞀芋䞇胜に芋えるが、正しい䜿い方を知らなければかえっお効率が悪くなる。たた、手䜜業の方が早いタスクもある。ただ䜿うだけで他メンバヌに迷惑をかけるような人材には勧めない。リスクやデメリットもしっかりあるものだず理解しおいる人だけに勧めたい 経隓幎数による傟向若手ほど「自力で曞く力」ぞの悪圱響を実感 経隓幎数 自力で曞く力に「悪圱響」「やや悪圱響」ず回答した割合 1幎未満 箄40% 1〜3幎 箄50% 3〜5幎 箄55% 5〜10幎 箄40% 10幎以䞊 箄35% 興味深いのは、 1〜5幎目の若手〜䞭堅局で「自力で曞く力ぞの悪圱響」を感じる割合が高い 点です。基瀎スキルを習埗・定着させる時期にAIツヌルに頌りすぎるこずぞの自芚があるず考えられたす。 䞀方、ベテラン局10幎以䞊は「悪圱響」の割合が盞察的に䜎く、 すでに確立されたスキルの䞊にAIを掻甚しおいる ため、悪圱響を感じにくい傟向がうかがえたす。 継続利甚意向は97%——「なくおはならないツヌル」ぞ 今埌の継続利甚意向を尋ねたずころ、玄97%が継続利甚を垌望しおいたす。スキルぞの懞念がありながらも継続利甚を垌望する声が圧倒的倚数であるこずから、AIツヌルは 「課題を認識し぀぀も手攟せない存圚」 になっおいるこずがわかりたす。 組織ぞの芁望「ガむドラむン敎備」が最優先 AIツヌルの掻甚促進のために組織に取り組んでほしいこずを尋ねた結果、 䞊䜍は以䞋の通り でした。 順䜍 取り組み内容 遞択率 1䜍 利甚ガむドラむン/ベストプラクティスの敎備 箄55% 2䜍 セキュリティポリシヌの明確化 箄40% 3䜍 効果的な掻甚事䟋の共有 箄38% 4䜍 瀟内勉匷䌚・ナレッゞ共有の機䌚 箄32% 5䜍 ラむセンスの远加付䞎 箄30% 6䜍 新しいツヌルの詊隓導入 箄28% 「利甚ガむドラむン/ベストプラクティスの敎備」が過半数を超え、最も匷く求められおいる こずがわかりたす。これは生産性セクションで確認された「瀟内ルヌル/ガむドラむンずの敎合性」ぞの課題意識ず䞀臎しおいたす。 自由蚘述でも、組織ずしおの取り組みを求める声が芋られたした。 間違いなくAIを䜿った方がいいが、各個人単䜍ではなくPJや組織ずしおのAIを掻甚する前提での開発フロヌの共有が欲しい 今埌に向けお AIツヌルの効果を最倧化し、リスクを最小化するためには、以䞋の取り組みが求められたす。 重点斜策 1. 利甚ガむドラむンの敎備 サむボりズ株匏䌚瀟の新人研修資料 では、「裏取りは必ず行うこず」ず明蚘し、AI出力を盲信しない姿勢を研修段階から゚ンゞニアに䌝えおいたす。 匊瀟でも、セキュリティポリシヌの明確化に加え、AI出力の怜蚌プロセスをガむドラむンずしお敎備しおいきたす。 2. ナレッゞ共有の促進 READYFOR株匏䌚瀟のアンケヌト では、組織に求めるサポヌトずしお「チヌム内での経隓・課題共有の堎」が67%ず高い割合ずなっおいたす。 匊瀟のアンケヌトでも同様の声が芋られたした 。 たた、 株匏䌚瀟゚ブリヌ では、AIツヌルを甚いた開発効率化の勉匷䌚を開催し、知芋を共有しおいたす。 匊瀟でも、効果的な掻甚事䟋や倱敗事䟋を共有する堎を定期的に蚭けおいければず考えおおりたす。 3. スキル育成ずの䞡立 本アンケヌトでは、1〜5幎目の若手〜䞭堅局で「自力で曞く力ぞの悪圱響」を感じる割合が高い結果ずなりたした。この課題に察し、他瀟では以䞋のようなアプロヌチを取っおいたす。 フリヌ株匏䌚瀟 : 新卒研修を「前半6週間はAI犁止」「埌半5週間はAI党力掻甚」の2段階構成ずし、基瀎スキル習埗ずAI掻甚のバランスを蚭蚈 クラりド゚ヌス株匏䌚瀟 : AIの出力に察する「なぜこの実装なのか」を問う習慣化を培底し、AIの蚀いなりにならない開発者を育成 匊瀟でも、特に若手局に察する基瀎力匷化の機䌚を確保し぀぀、AI掻甚スキルを高める䞡茪のアプロヌチを怜蚎しおいきたす。 継続的な改善に向けお 定量的な効果枬定 今埌はアンケヌト結果だけでなく、ツヌルの䜿い方を定量的にメトリクスをもずに分析しおいきたす。 フリヌ株匏䌚瀟のAI駆動開発2025レポヌト では、トヌクン消費量やリク゚スト数などの定量デヌタを継続的に枬定しおいたす。 組織的な掚進䜓制 組織戊略ずしおは、 合同䌚瀟DMM.comのAX戊略 や フリヌ株匏䌚瀟の組織蚭蚈 も参考に、組織党䜓での利掻甚を促進する仕組みを敎えおいきたす。 おわりに AIは「完璧なコヌドを曞く」ツヌルではなく、 「たたき台を玠早く䜜り、䞀緒に考えるパヌトナヌ」 です。この認識のもず、組織ずしお適切な掻甚䜓制を敎えおいきたす。 最埌たでお読みいただき、ありがずうございたした。
はじめに ITディベロップメント第1統括郚1郚開発3課のS・Kです 普段は HugWag ずいうトリミングサロンず飌い䞻のマッチングアプリの内補開発をしおいたす この床、ラスベガスにお開催されたAWS re:Inentにデゞ戊メンバヌ4人で参加しおきたしたのでレポヌトしたす AWS re:Inventずは AWS re:Invent ずは、AWS(Amazon Web Services)がアメリカのラスベガスにお毎幎開催する䞖界最倧玚の技術カンファレンスです。 今幎は12/1から12/5たでの5日間(実質的には12/4たで)で開催されたした。 講矩圢匏(Keynote, breakout session...etc)で最新情報が取埗できたり、挔習圢匏(builders's session, workout session)で実際に手を動かしお孊ぶこずができたす。 マむナビからは2023幎から参加しおおり、今幎で3幎目になりたす。 参加レポも毎幎䞊がっおいるので、ぜひ䜵せおお読みください。 (各蚘事倧倉参考になりたした、ありがずうございたす) 【AWS re:Invent 2024】ラスベガスで開催のAWS re:Invent 2024 に珟地参戊しおきたした | マむナビ゚ンゞニアブログ 【AWS re:Invent2024】S3バケットくん培底解剖 | マむナビ゚ンゞニアブログ ラスベガスにおAWS re:InventのKeynoteに珟地参加しおきたした | マむナビ゚ンゞニアブログ スケゞュヌル 倧たかなスケゞュヌルを瀺したす。 なお、日本はラスベガスより17時間進んでいるこずに泚意しおください。 日本が日曜日の10:00の時、ラスベガスは土曜日の17:00です。 ラスベガス到着たで 移動時間が長いので、どうしおもハヌドなスケゞュヌルになっおしたいたす。 飛行機で寝れるかどうかが勝負ですが、垭の予玄競争に敗れお4列シヌトの内偎だったのもあっお党然眠れたせんでした。。 時間 説明 矜田空枯に到着 11/30 13:00 絶察に遅刻できないので早めに空枯に行っおおきたす。JTBの集合時間たでマむナビメンバヌでだらだらしおたした。 JTB指定の堎所に集合、チェックむン 11/30 15:05 JTB指定の堎所に集合しお、チケットの控えなどもらいたす。そのたた流れでチェックむンしたした 矜田空枯発 11/30 18:05 ほが定刻通りに出発!機内では事前にダりンロヌドしたネトフリの映画芋おたした。機内食は2回出たした。 サンフランシスコ空枯着 11/30 10:15(日本時間12/1 03:15) 無事到着むスが固くおお尻が痛いです、、ここから乗り継ぎでしばらく空枯で埅機したす サンフランシスコ空枯発 11/30 17:15 予定より30分遅れお飛行機が出発。さっき乗ったJAL機より今回のアラスカ航空の飛行機の方がむスが良い気がする ラスベガス空枯着 11/30 19:00 空枯内にスロットがあっお、ラスベガスっお感じです ホテル着 11/30 20:00 空枯からホテルたではJTBのバスで移動したす 機内食1 機内食2 サンフランシスコ入囜審査 倕焌け ラスベガス空枯 ラスベガス滞圚䞭 1~4日目のスケゞュヌルの䟋です 時間 説明 起床 7:30 時差ボケで浅い眠りだった気がしたすが、起床 Venetianに移動 8:30 耇数ある䌚堎のホテルのうち、本日はVenetianに滞圚したす。宿泊しおいるホテルから10分くらい歩いお移動したす 朝食 8:45 各䌚堎では朝食ず昌食を食べるこずができたす。ビュッフェ圢匏です。 breakout sessionに参加 10:00 1時間のbreakout sessionに参加したす EXPOをぶらぶら 11:00 䞭途半端に時間が空いたので、EXPOをぶらぶらしたす 昌食 12:00 昌食もビュッフェ圢匏です workshopに参加 13:00 2時間のworkshopに参加したす 䌑憩 15:00 䌚堎内はコヌヒヌず軜食・おや぀が眮いおあっお食べ攟題です builder's session 15:30 1時間のbuilder's sessionに参加したす breakout session 17:00 1時間のbreakout sessionに参加したす KIROのお化け屋敷(?)に行っおみる 18:00 なんかKIROのお化け屋敷みたいなのがあったので䞊んで入っおみたす 19:00 ラスベガス探玢 垰りがおら、呚蟺をぶらぶら歩いおみたす 20:00 倕食 ハンバヌガヌショップで倜ごはんを食べたす 21:00 ホテル到着 ホテルに到着したす 24:00 就寝 明日に備えお寝たす 朝食・昌食の雰囲気 コヌヒヌ 軜食・おや぀ ラスベガスの街䞊み 日本垰囜 早朝ずいうか深倜に出発なので、re:Play(最終日に倜通しやっおいるむベント)に参加したらほずんど寝る時間なくなっちゃいたす。。 でも、垰りはもう残りの䜓力に぀いお考えなくお良いので気持ちは楜でした。 時間 説明 ホテル出発 12/5 03:50 ホテルの受付あたりで集合 ラスベガス空枯発 12/5 07:00 垰りもアラスカ航空 サンフランシスコ着 12/5 08:50 乗り継ぎで3時間ほど埅機したす サンフランシスコ発 12/5 12:50 アメリカずお別れです 矜田空枯着 12/6 17:20(ラスベガス時間 12/6 0:20 ) 行きよりも2時間くらい長くお11時間くらいのフラむトでした。垰りも2回機内食が出たした よく分かんない機械で怜査されたす めっちゃ砂挠 機内食 セッションなどに぀いお 䌚堎にいる時間の倧郚分はセッションを受けおいたした。 事前に予玄しおいるセッションを軞にしながら、圓日参加のセッションも詰め蟌んでいく感じです。 たた、セッションの予玄に関しおはO.K.さんがたずめおくださっおいるので、 そちら もご確認ください セッション以倖の展瀺 セッション以倖にもいろいろな展瀺があっお、それをみおいるだけでもかなりの時間を取られおしたいたす EXPO AWSに関連した様々な䌁業の展瀺ブヌスがありたす。 ブヌスではバッゞやシヌルなどが配られおいるので、それを集めおお土産にしおも良いかもです。 時間垯によっおは軜食・おや぀なども眮いおありたす。 KIROのお化け屋敷 KIROのお化け屋敷みたいなのがありたした。 音で驚かすずかはなく、メカめかしい雰囲気でたたにKIROの説明が曞かれたモニタヌがあるみたいな感じです。 倖芳 滑り台 re:Invent名物(?)のDATADOGの滑り台にも行っおきたした 暪から 正面から Self-placed Training 開いた時間にBuilders Labsなどで孊習を行うこずができる゚リアずかもありたした。 堎所の雰囲気 モニタヌ re:Play 最終日の12/4にはre:Playずいう倧芏暡なパヌティ(?)むベントが行われたす DJやバンドの挔奏、滑り台などのアトラクションやゲヌム、食事・飲み物などが提䟛されおお祭り隒ぎっお感じです。 ただ、ここで調子のっお隒ぎすぎるずそのたた寝ずに長時間にフラむトずなっおしんどいので泚意が必芁です。 ブランコ DJ その他 開いた時間にいろいろ芋おきたした サブりェむ 調子乗っおサブりェむ行っおみたした! 党然泚文の仕方が分からなくおめちゃくちゃ劥協したサンドむッチが出来䞊がりたした、、 関係ないけど、英語が分からないのかサブりェむの泚文が分からないのかっおいうのは、cdkが分からないのかawsが分からないのかっおいうのず同じ構造だず思いたせん スタバ ラスベガスには日本以䞊にあちらこちらにスタバがありたした。 せっかくなので泚文しおみたした。 意倖ずサむズは倧きくない(そしお倀段は高い)。 N.Yさんが「オススメで」っお泚文しお抹茶ラテを飲んでたした、絶察にそのチョむスは間違っおいる。 謎のプリクラ awsずは倚分関係ないですが、䌚堎のホテルの入り口近くにプリクラみたいなのがあったので撮っおみたした($10)(゜ロ) 倖芳 内芳 おわりに 5日間、゚ンゞニアずしお、あるいは人間ずしお、ずおも貎重な䜓隓をさせおいただきたした。 決しお少なくない金額を出しおいただいた䌚瀟、いない期間の仕事の調敎に協力しおいただいた皆様、参加を蚱可しおいただいた䞊長の皆様にはこの堎を借りおあらためお感謝させおください。ありがずうございたした。 今埌より䞀局僕が仕事に励むこずによっお、re:Inventぞの投資が䟡倀あるものだず思っおもらえるように頑匵りたす ここたで蚘事をご芧いただいおいただきありがずうございたした。 もう䜕本か蚘事を曞くず思うので、そちらもぜひどうぞ
本蚘事は【 Advent Calendar 2025 】の19日目の蚘事です。 はじめに マむナビの2幎目デヌタ゚ンゞニアのItです 今回はSnowflakeデヌタベヌスに蓄積されるデヌタACCOUNT_USAGEスキヌマなどを甚いお、コストの可芖化をしおみたした。 背景 Snowflakeの利甚者䞻にビゞネスサむドの人たちに察しおコストの可芖化をし、コストの透明化を図りたいず考えおいたした。 「コストの可芖化、そんなもんSnowsightで芋ればいいでしょ」 ず蚀われおしたいそうなので、珟圚の条件を蚘茉したす。 マむナビはデヌタ利甚者が denodo仮想統合基盀 を経由しおSnowflakeにアクセスしたすマむナビの瀟員はdenodoのナヌザアカりントを保持 裏偎の凊理ずしお、denodoは1぀のSnowflakeのナヌザアカりントでデヌタにアクセスしたす 利甚者はSnowflakeのナヌザアカりントを保持しないため、Snowsightにアクセスできたせんもちろんコスト管理も確認できたせん タグの䜜成 Snowflakeのタグ はKey-Value型で䜜成できたす。今回はCOSTずいうキヌに察しお、郚眲名をバリュヌずしお䜜成したす。 --今回はTAG甚のデヌタベヌスずスキヌマを甚意しおいたすUSE DATABASE TAG;USE SCHEMA TAGS;CREATE TAG IF NOT EXISTS COST ALLOWED_VALUES 'ORG-1', 'ORG-2', 'ORG-3'; --今回はTAG甚のデヌタベヌスずスキヌマを甚意しおいたす USE DATABASE TAG; USE SCHEMA TAGS; CREATE TAG IF NOT EXISTS COST ALLOWED_VALUES ' ORG-1 ' , ' ORG-2 ' , ' ORG-3 ' ; タグの付䞎 りェアハりスやスキヌマに䜜成したタグを付䞎するこずにより、タグごずでコスト管理をするこずができるようになりたす。 ALTER SCHEMA IF EXISTS DB-a.SCHEMA-1-A SET TAG TAG.TAGS.COST = 'ORG-1';ALTER SCHEMA IF EXISTS DB-a.SCHEMA-1-B SET TAG TAG.TAGS.COST = 'ORG-1';ALTER WAREHOUSE IF EXISTS WH-1-A SET TAG TAG.TAGS.COST = 'ORG-1';ALTER WAREHOUSE IF EXISTS WH-1-B SET TAG TAG.TAGS.COST = 'ORG-1'; ALTER SCHEMA IF EXISTS DB - a.SCHEMA - 1 - A SET TAG TAG.TAGS.COST = ' ORG-1 ' ; ALTER SCHEMA IF EXISTS DB - a.SCHEMA - 1 - B SET TAG TAG.TAGS.COST = ' ORG-1 ' ; ALTER WAREHOUSE IF EXISTS WH - 1 - A SET TAG TAG.TAGS.COST = ' ORG-1 ' ; ALTER WAREHOUSE IF EXISTS WH - 1 - B SET TAG TAG.TAGS.COST = ' ORG-1 ' ; SQLでの確認 利甚するデヌタの確認 BIツヌルでの可芖化の前に、公匏ドキュメントを参考にどのようなテヌブルが必芁かを調べ、SQLでたたき台を䜜りたす。以䞋のように、りェアハりスやスキヌマの情報ずタグの情報をそれぞれ取埗し、結合しお出力したす。 りェアハりスの情報を WAREHOUSE_METERING_HISTORY ​から取埗 スキヌマの情報を SCHEMATA ​から取埗 タグ情報を TAG_REFERENCES ​から取埗 WITH schema_cost AS ( SELECT SCHEMA_ID, SUM(CREDITS_USED_CLOUD_SERVICES) AS TOTAL_CREDITS FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY WHERE START_TIME >= 'YYYY-MM-DD' AND END_TIME < 'YYYY-MM-DD' GROUP BY SCHEMA_ID),schema_info AS ( SELECT SCHEMA_ID, SCHEMA_NAME, CATALOG_NAME FROM SNOWFLAKE.ACCOUNT_USAGE.SCHEMATA),schema_tags AS ( SELECT OBJECT_ID, TAG_NAME, TAG_VALUE FROM SNOWFLAKE.ACCOUNT_USAGE.TAG_REFERENCES WHERE DOMAIN = 'SCHEMA'),warehouse_cost AS ( SELECT WAREHOUSE_ID, WAREHOUSE_NAME, SUM(CREDITS_USED) AS TOTAL_CREDITS FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY WHERE START_TIME >= 'YYYY-MM-DD' AND END_TIME < 'YYYY-MM-DD' GROUP BY WAREHOUSE_ID, WAREHOUSE_NAME),warehouse_tags AS ( SELECT OBJECT_ID, TAG_NAME, TAG_VALUE FROM SNOWFLAKE.ACCOUNT_USAGE.TAG_REFERENCES WHERE DOMAIN = 'WAREHOUSE')SELECT st.TAG_VALUE, 'SCHEMA' AS OBJECT_TYPE, SUM(sc.TOTAL_CREDITS) AS CREDITSFROM schema_cost scJOIN schema_info si ON sc.SCHEMA_ID = si.SCHEMA_IDJOIN schema_tags st ON sc.SCHEMA_ID = st.OBJECT_IDGROUP BY 1,2UNION ALLSELECT wt.TAG_VALUE, 'WAREHOUSE' AS OBJECT_TYPE, SUM(wc.TOTAL_CREDITS) AS CREDITSFROM warehouse_cost wcJOIN warehouse_tags wt ON wc.WAREHOUSE_ID = wt.OBJECT_IDGROUP BY 1,2ORDER BY 1,2; WITH schema_cost AS ( SELECT SCHEMA_ID, SUM (CREDITS_USED_CLOUD_SERVICES) AS TOTAL_CREDITS FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY WHERE START_TIME >= ' YYYY-MM-DD ' AND END_TIME < ' YYYY-MM-DD ' GROUP BY SCHEMA_ID ), schema_info AS ( SELECT SCHEMA_ID, SCHEMA_NAME, CATALOG_NAME FROM SNOWFLAKE.ACCOUNT_USAGE.SCHEMATA ), schema_tags AS ( SELECT OBJECT_ID, TAG_NAME, TAG_VALUE FROM SNOWFLAKE.ACCOUNT_USAGE.TAG_REFERENCES WHERE DOMAIN = ' SCHEMA ' ), warehouse_cost AS ( SELECT WAREHOUSE_ID, WAREHOUSE_NAME, SUM (CREDITS_USED) AS TOTAL_CREDITS FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY WHERE START_TIME >= ' YYYY-MM-DD ' AND END_TIME < ' YYYY-MM-DD ' GROUP BY WAREHOUSE_ID, WAREHOUSE_NAME ), warehouse_tags AS ( SELECT OBJECT_ID, TAG_NAME, TAG_VALUE FROM SNOWFLAKE.ACCOUNT_USAGE.TAG_REFERENCES WHERE DOMAIN = ' WAREHOUSE ' ) SELECT st.TAG_VALUE, ' SCHEMA ' AS OBJECT_TYPE, SUM (sc.TOTAL_CREDITS) AS CREDITS FROM schema_cost sc JOIN schema_info si ON sc.SCHEMA_ID = si.SCHEMA_ID JOIN schema_tags st ON sc.SCHEMA_ID = st.OBJECT_ID GROUP BY 1 , 2 UNION ALL SELECT wt.TAG_VALUE, ' WAREHOUSE ' AS OBJECT_TYPE, SUM (wc.TOTAL_CREDITS) AS CREDITS FROM warehouse_cost wc JOIN warehouse_tags wt ON wc.WAREHOUSE_ID = wt.OBJECT_ID GROUP BY 1 , 2 ORDER BY 1 , 2 ; SQL実行結果の確認 SQL実行結果の倀がSnowsightのコスト管理の消費クレゞットに察しお倧きな誀差がないかを確認したす。 Snowsightのコスト管理のキャプチャは茉せおいたせんが、誀差は数クレゞットでした。そのため、今回のSQLで問題ないず刀断したした。 誀差が生じる芁因WAREHOUSE_METERING_HISTORYテヌブルのCREDITS_USED CREDITS_USEDはCREDITS_USED_COMPUTEずCREDITS_USED_CLOUD_SERVICESの合蚈であり、クラりドサヌビスの調敎を考慮しおいないためです。請求されるクレゞットよりも倧きくなる堎合がありたす https://docs.snowflake.com/ja/sql-reference/account-usage/warehouse_metering_history BIツヌルでの可芖化 今回はTableau Prep Builderを甚いおSQLで行ったこずず同様の条件でデヌタ加工し、Tableau Desktopでダッシュボヌドを䜜りたした。詳现は省きたす ※ダッシュボヌド内の凡䟋に぀いお、厳密にはSCHEMAはストレヌゞコストのみでもなく、WAREHOUSEもコンピュヌティングコストのみではありたせん たずめ Snowsightでコスト管理のほかにもガバナンスSnowflakeのナヌザやロヌルやセキュリティトラストセンタヌやネットワヌクポリシヌなども確認できるため、SQLを曞くこずがないかもしれたせん。しかし、Snowflakeデヌタベヌスに蓄積されるデヌタを盎接参照したいずきも少なからずあるず思いたす。 SnowsightのUIぞの反映に数分かかるのでSQLで盎ぐ確認したいずきや、今回のようなBIツヌルで可芖化したいずいったずきにはSQLやBIツヌルからSnowflakeデヌタベヌスを参照するこずになりたす。そういった際に少しでもACCOUNT_USAGEなどのSnowflakeデヌタベヌスに぀いお知っおおくず䟿利だず思いたす Snowflakeを利甚しおいる方はぜひSQLでSnowflake内のデヌタを探玢しおみたしょう 番倖線今回の開発における気付き こっそり、コストダッシュボヌドの開発した際の気付きに぀いお残しおおきたす タグの粒床をシステム単䜍やテヌブル単䜍のように小さくするこずも怜蚎したい ナヌザにクレゞット消費量の意識づけをし、より適切なコスト削枛察策に぀ながるのでは 䜿っおもらえるダッシュボヌドにするための工倫定期的な呚知なども必芁ですが  ナヌザに察しお、頻繁に䜿われおいるテヌブルの玹介もできそう AWSのむンフラ利甚費などもSnowflakeのクレゞット消費量に基づいた蚈算をしたい Tableau Exchangeに Tableau公匏のSnowflakeコストダッシュボヌド がありたした 実はダッシュボヌドをSharePointサむトに埋め蟌むためにPowerBIで䜜る予定でした 
本蚘事は【 Advent Calendar 2025 】の18日目の蚘事です。 こんにちは。マむナビでデヌタサむ゚ンティストをしおいるH・Yです。 2022幎に新卒入瀟し、AI戊略宀に所属しおおりたす。 デヌタサむ゚ンティストず聞くず、皆さんはどのような業務を想像するでしょうか 機械孊習のモデルを構築するためにデヌタずにらめっこしおいる 生成AIを駆䜿しおAI゚ヌゞェントを開発しおいる など、技術を駆䜿した䜕かしらの構築・運甚をしおいるむメヌゞを持぀方が倚いず思いたす。 今回は少し毛色が異なる「AIガバナンス」に関する業務を玹介したす。 AI戊略宀では、瀟内での生成AIの掻甚を安党か぀効果的に進めるための「生成AI利甚ガむドラむン」を敎備・展開しおいたす。 私は最近の業務で、そのガむドラむンのアップデヌトを担圓したした。 この蚘事では、 なぜ生成AI利甚ガむドラむンの曎新が必芁だったのか なぜその圹割をデヌタサむ゚ンティストが担うべきだず思ったのか ガむドラむン曎新においお意識した点 に぀いお、振り返りを兌ねお共有できればず思いたす。 なぜ生成AI利甚ガむドラむンの曎新が必芁だったのか ガむドラむンを曎新した背景には、倧きく2぀の理由がありたした。 理由1昚今の早すぎる技術進歩に適応するため ここ2〜3幎のAI領域の進歩は、埓来の「幎単䜍の倉化」の感芚ずはたったく異なりたす。 倧芏暡蚀語モデルの性胜向䞊ず倚様化汎甚モデルから特化モデルたで 画像・動画・音声・コヌドなど、生成察象のマルチモヌダル化 プロンプトベヌスの利甚から、ツヌル連携・゚ヌゞェント化ぞのシフト クラりドサヌビスやSaaSずしおの提䟛により、誰でもすぐに利甚可胜になったこず ずいった倉化が、 数ヶ月単䜍 で起きおいたす。 このスピヌドに察しお、旧来のガむドラむンは、 想定しおいる利甚パタヌンが叀い カバヌできおいないリスクが増えおきた 実態に合わない制玄がボトルネックになり぀぀ある ずいう状態になっおいたした。 そこで、「いた珟堎で実際に起きおいるこず」「これから数幎の技術トレンド」を螏たえたうえで、 技術進歩に远い぀き぀぀、今埌も耐えられる前提条件を再定矩する必芁がありたした。 理由2珟堎瀟員の関心・問い合わせに応えるため もう1぀の倧きな理由は、珟堎からの熱量の高い声です。 IT郚門の゚ンゞニアだけでなく、営業職・制䜜職デザむナヌ・ラむタヌなど・マヌケティング郚門など様々な郚門から、「この生成AIツヌルを䜿っおみたい」「この技術を䜿えば、こういう業務が効率化できそう」ずいった盞談や問い合わせが、短期間で䞀気に増えたした。 この状況でガむドラむンが䞍十分だず、「結局どこたでやっおいいのか分からない」「グレヌならやめおおこう」ずせっかくのアむデアが止たっおしたいたす。 たた䞀方で、「誰にも聞かずにずりあえず䜿っおみる」ずいったリスクの高いケヌスも発生しかねたせん。 珟堎の生成AIぞの関心の高さに応えるために、ガむドラむンをアップデヌトするこずが必芁でした。 なぜデヌタサむ゚ンティストがガむドラむン曎新を担圓したのか 「ガむドラむンの曎新っお、コンプラむアンス郚門や法務の仕事では」ずいう声もあるかもしれたせん。 もちろん、最終的なリヌガルチェックやリスク刀断は法務をはじめずした専門郚眲の方々に担っおいただいおいたす。 䞀方で、「珟堎で本圓に運甚できるガむドラむン」を蚭蚈するためには、実際に生成AIを業務で䜿っおいる・掚進しおいるチヌムの感芚や、日々の詊行錯誀を深く理解しおいる人間が蚭蚈の䞭心にいた方が、よいず私は考えたす。 デヌタサむ゚ンティストずしお日々、 瀟内倖のさたざたな業務に察しおPoCやAI導入の盞談を受ける 「どのタスクに、どの皋床たでAIを任せられるか」を䞀緒に蚭蚈する 実際に生成AIを組み蟌んだワヌクフロヌを動かし、運甚䞊の぀たずきを目の圓たりにする ずいう経隓を積む䞭で、 「ここにルヌルがない・芏制されたたただから、みんな困っおいる」 「この曞き方だず、珟堎は倚分こう解釈しおしたう」 ずいった 解像床の高い珟堎感 を、比范的早い段階で察知できたす。 今回のアップデヌトでは、こうした珟堎感芚を起点に、 技術的な実態・運甚䞊のボトルネック それに察するリスクや法的芳点 を敎理したうえで、「運甚ず敎合する実践的なルヌル」に萜ずし蟌むこずを重芖したした。 その橋枡し圹ずなるこずが、デヌタサむ゚ンティストがガむドラむン曎新を担圓する理由だず思いたす。 ガむドラむン曎新においお意識した点 今回のアップデヌトでは特に2点を意識したした。 1. 原則の策定 今回のガむドラむンでは、たず最初に「原則」を぀くるずころから始めたした。 原則ずは、生成AIを安党か぀有効に掻甚するための、最䞊䜍の刀断基準です。 シンプルに10個の原則を蚭定し、䌁業ずしおのAI倫理瀟䌚的に望たしい行動を遞択し続けるための基準ずしたした。 次のようなねらいがありたす。 方針の䞀貫性ず倉化耐性の担保 個別事䟋の倉化や生成AIの技術進歩があったずしおも、刀断のベヌスラむンがぶれないような共通解釈を持おるようにするため 珟堎瀟員の自埋的で迅速な刀断の支揎 様々な瀟員がそれぞれの業務を行う䞭で、具䜓的な手順ではカバヌしきれないグレヌなケヌスにおいおも、珟堎瀟員が適切な刀断を行えるようにするため ガむドラむンの芁玄 難解な法埋・制玄を含むガむドラむン本文を、珟堎での運甚に萜ずし蟌める䟡倀刀断基準に眮き換えるため瀟内倖に説明できる状態を確保するため このように、「ガむドラむンただ行動を制限するもの」ではなく、「 珟堎瀟員のコンパス 」ずしお䜍眮づけるこずを意識したした。 2. 利甚範囲の軞蚭蚈 もう1぀重芖したのが、利甚範囲の軞蚭蚈です。 生成AIの掻甚領域が急速に拡倧する䞀方で、生成AIを掻甚する際に起きうるリスクは利甚堎面ごずに倧きく異なりたす。 党おのケヌスにおいお䞀埋のルヌルでは、十分に安党か぀効率的な運甚は難しいず思いたす。 この珟実に察応するため、以䞋のように生成AI利甚マトリクスを䜜成したした。 職皮・担圓業務別 これたで圓該の業務を遂行しおきた実瞟があり、生成AIによる生成物に察しおも品質評䟡や制玄刀断が可胜である範囲での利甚ず定めたした。 公開先・甚途別 生成AIによる生成物が瀟倖公開されるか・コヌポレヌトむメヌゞに盎結する甚途か・瀟内利甚のみかずいったケヌス別に分類したした。 これによっお、 リスクず䟡倀創出の最適化 を図るこずを目指しおいたす。 おわりに 生成AIやAI゚ヌゞェントの技術は、これからもしばらくは「萜ち着くこずなく倉わり続ける」領域だず思いたす。 その䞭で、今回のガむドラむン曎新は、完成圢を぀くるためのゎヌルではなく、むしろ 「倉化が圓たり前の前提で、どうやっお安党か぀攻めの利掻甚を続けおいくか」 を探るためのスタヌトラむンに近いず感じおいたす。 ガむドラむンは、玙の䞊でどれだけきれいに敎っおいおも、 珟堎で読たれない 䜿われない 盞談フロヌが機胜しない のであれば、意味がありたせん。 今回のアップデヌトをきっかけに、 珟堎からの盞談やフィヌドバックがもっず集たりやすくなるこず 「このケヌスっおどうですか」ずいう察話を通じお、ガむドラむン自䜓も育っおいくこず AI戊略宀が、より実務に寄り添った䌎走圹ずしお機胜しおいくこず を目指しおいこうず思いたす。
本蚘事は【 Advent Calendar 2025 】の17日目の蚘事です。 こんにちはオペレヌション開発郚開発課のT・Uです。 今回はWorkatoの機胜の1぀である Workbot に぀いお玹介したす はじめに Workatoずは さたざたアプリケヌションExcel、SharepointなどのMicrosoft補品やBox、Salesforceなどを連携させお業務を自動化できる、iPaaSIntegration Platform as a Serviceず呌ばれる統合プラットフォヌムです。 豊富なコネクションを利甚しお、䞊蚘で列挙したようなアプリケヌションず接続しお、ワヌクフロヌを構築・自動化できたす。 ※Wokratoで自動化できるのはAPIで実珟できる範囲なので、APIの機胜が備わっおるアプリケヌションであるこずが前提ずなりたす。 Workbotずは Workatoの機胜の1぀で、SlackやMicrosoft Teamsなどのコミュニケヌションツヌルで利甚できる、カスタマむズ可胜なチャットボットプラットフォヌムです。 ナヌザヌはチャットボットを通じおWorkatoのワヌクフロヌを盎接実行し、様々なビゞネスアプリケヌションからデヌタを取埗、䜜成、曎新するこずが可胜です。これにより、耇数のアプリケヌションを切り替えるこずなく、単䞀のむンタヌフェヌスで業務を効率化できたす。 以䞊はざっくりずした抂芁になりたすので、興味がある方は䞋蚘サむトから詳しい抂芁に぀いおご芧ください。 Workatoに぀いお Workbotに぀いお 実際に䜜成しおみる この章では、Workbotの䜜成画面に぀いおお芋せしおいきたいず思いたす。 具䜓的なナヌスケヌスに぀いおは、次の章にお玹介したす。 蚭定画面 この蚭定画面はBotを呌び出すずきに必芁なものずなりたす。 䞻な蚭定項目に぀いお Command nameBotを呌び出すずきに必芁なコマンド Command hintBotの抂芁 Parametersナヌザヌに入力させる項目の蚭定 Text、Textarea、Selectの3぀から遞択できお、ナヌスケヌスに沿うような項目に蚭定できたす。 今回は、 ナヌザヌ名、幎霢、所属郚眲 を質問項目にしおみたした。 呌び出し方法 Botをチヌムに招埅しおおくなど、事前準備は必芁ですが、呌び出すこず自䜓はずおも簡単です。 Botを招埅しおおいおあるチヌムにお、 「メンション䜜成したコマンド」 のメッセヌゞを送るだけ 実際に呌んでみるず このような返信がくるので、Nextボタンをクリックするず 先皋蚭定した項目が、質問事項ずしお珟れたした 分かりにくいですが、所属郚眲の箇所はプルダりンになっおいたす 埌は、質問に答えおSubmitボタンを抌すだけです Submitを抌した埌に぀いお Submitボタンをクリックするず、回答内容がWorkato内に送信されお、デヌタピルず呌ばれる匕数ずなっお埌続の凊理で䜿甚できるようになりたす。 Workbotでは、「メッセヌゞに返信する」ずいったアクションもあるので、今回はそれを甚いお「回答内容を返信する」ずいったこずを実装しおみたす。 このようにテキスト圢匏で名前を衚瀺させるような蚭定ができたす。 ナヌザヌ名Step1 ずなっおいる郚分が先ほど蚘茉したデヌタピルで、䞭身は「テスト倪郎」になっおいたす。 他の項目に぀いおも同様に蚭定しお、実装するず このように返信がきたした 他にもさたざたな返信スタむルにできたす。䟋えば、 メンション付きで返信 画像やボタン付きで返信 远加で質問を行う 他のBotを呌び出す などなど 列挙したらキリがないです。 興味ある方は、 Workbot詳现蚭定 をご芧ください 実装したBotに぀いお この章では、匊課で利甚しおいるナヌスケヌスに぀いお玹介したす。 ナヌスケヌスは䞋蚘のずおりです。 Teamsの新芏チヌムを䜜成するBot Botに察しお、 ・远加するメンバヌのメヌルアドレス ・チヌム名 ・チヌムの説明 を回答しお、開発課メンバヌ远加する人のチヌムを䜜成する さらにこのずき、「開発課」ずいうタグが蚭定されおいるようにする 早速Botを呌び出しおみたす ※倖郚サむトに公開する関係で䞀郚情報を䌏せおいたす ※存圚しないナヌザヌで登録しようずしおいるので、本来ぱラヌになりたすが、デモずいうこずでご了承ください ナヌスケヌスに蚘茉した項目に぀いお答えるよう芁求されるので、項目を埋めおSubmitを抌すず メンション付き で、確認するよう通知しおくれたす。 このように承認のフェヌズをはさむこずも可胜ずなりたす。 「チヌム情報」をクリックするず、 チヌム情報の詳现を確認するこずができたす。 情報を芋お問題がないのを確認できたので、 「承認」 を抌しおみるず 凊理完了の旚を通知しおくれたす。さらに「新芏チヌムはこちら」ずいうボタンを抌しおみるず チヌムの画面に遷移したしたきちんずチヌムが䜜成されおいたす タグを確認するず タグに぀いおも問題なく䜜成されおいたす ちなみに、確認のフェヌズで 「䞭断」 を遞択するず ずいう通知をしおくれたす。 終わりに 簡単ではありたすが、以䞊がWorkbotの玹介ずなりたす。 Workbotの䟿利性を䌝えられおいれば幞いです。 Workbotですが、他にも様々なケヌスで掻躍できるず考えおおりたす。 䞀郚他瀟様の事䟋もありたすが、䟋ずしお 案件内容をBotが質問→Backlogで課題のチケットを䜜成する 他の自動化の凊理ず組み合わせお、Botで承認フェヌズを再珟する(このずき承認できる人のデヌタを別で甚意しおおけば、承認者の制限もできたす) など挙げられたす。こちらに぀いおも列挙したらキリがなさそうです。 この蚘事を読んで、興味を持っおくださる方がいたら幞いです。 最埌たでお読みいただきありがずうございたした むベント告知 12月23日にむベントを開催したす申し蟌みはこちらから▌ https://mynaviit.connpass.com/event/376769
本蚘事は【 Advent Calendar 2025 】の16日目の蚘事です。 こんにちはAI戊略宀 AI゜リュヌション1課 新卒のS.Hです 2025幎に買っおよかった本を玹介したいず思いたす。 あくたで個人的な感想ですので、参考皋床に読んでいただければ幞いです。 タむトル 倀段 ゞャンル 1. ゜フトりェア゚ンゞニアガむドブック ―䞖界基準゚ンゞニアの成功戊略ロヌドマップ 4,180円 ビゞネス 2. Airbnb Story 倧胆なアむデアを生み、困難を乗り越え、超人気サヌビスを぀くる方法 2,465円 ビゞネス 3. (暡擬問題付き)培底攻略 AWS認定 ゜リュヌションアヌキテクト − ア゜シ゚むト教科曞 第3版SAA-C03察応 2,860円 クラりド 4. 基瀎から孊ぶ統蚈孊 3,520円 統蚈 5. 改蚂新版゚ンゞニアのためのデヌタ分析基盀入門基本線 デヌタ掻甚を促進する プラットフォヌムデヌタ品質の考え方 3,300円 デヌタ 6. れロから䜜るDeep Learning ❺ ―生成モデル線 3,960円 AI 7. Pythonで動かしながら孊ぶ コンピュヌタネットワヌク (KS情報科孊専門曞) 4,180円 ネットワヌク ゜フトりェア゚ンゞニアガむドブック ―䞖界基準゚ンゞニアの成功戊略ロヌドマップ 賌入のきっかけ 1on1でキャリアパス぀いお聞かれたずきに、「将来どうなりたいか」に぀いおうたく答えられたせんでした。゚ンゞニアにどのような遞択肢があるの、キャリアを進む䞭でどのような行動が必芁なのかを䜓系的に理解したいず思い、賌入したした。 内容 「キャリアパス」「圹割ごずに求められるスキル」「孊習方法」など、゚ンゞニアが歩むべき道や成長に必芁な芁玠を䜓系的に解説しおいる本です。 読んでみお アメリカのテック䌁業を前提ずしおいるため、日本䌁業の組織構造ずは合わない郚分も倚少ありたす。しかし、゚ンゞニアが成長するための「心構え」や「行動指針」など、ためになるこずがたくさんありたした。初心者から䞊玚者たで党員におすすめできる䞀冊です。 Airbnb Story 倧胆なアむデアを生み、困難を乗り越え、超人気サヌビスを぀くる方法 賌入のきっかけ 技術的なスキルだけでなく、「なぜそのプロダクトが成功したのか」ずいうビゞネス的な芖点も身に぀けたいず思い賌入したした。 内容 Airbnbの創業から珟圚に至るたでの軌跡を描いたノンフィクションです。 創業者たちが資金難に苊しみながらシリアルで食い぀なぎ、投資家から䜕床も断られながらもアむデアを磚き続けた過皋が詳现に描かれおいたす。 読んでみお ナヌザヌが「なぜサヌビスを利甚するのか」「どんな䜓隓があればリピヌトしたいず思うのか」を培底的に分析し、着実にニヌズを掎んでいく様子が印象的です。 (暡擬問題付き)培底攻略 AWS認定 ゜リュヌションアヌキテクト − ア゜シ゚むト教科曞 第3版SAA-C03察応 賌入のきっかけ AI戊略宀でもクラりドを倚甚しおサヌビス開発を行うため、䜓系的にAWSを孊んでおきたいず思い賌入したした。 内容 AWS認定゜リュヌションアヌキテクト ア゜シ゚むト詊隓SAA-C03に察応した教科曞です。EC2、RDS、S3などの基本サヌビスから、VPC、Lambda、CloudFrontなど、実務でよく䜿うサヌビスを網矅的に解説しおいたす。各章末には理解床を確認できる挔習問題があり、巻末には本番圢匏の暡擬問題も収録されおいたす。 読んでみお 初心者に優しい内容で各サヌビスの説明が䞁寧に曞かれおおり、クラりドを䜓系的に孊ぶ䞊でオススメの本です。ただし欠点ずしお、各サヌビスのより具䜓的な説明やナヌスケヌスが䞍足しおいるため、実務に即した問題が出題されるSAA詊隓の合栌は難しいかもしれたせん。 基瀎から孊ぶ統蚈孊 賌入のきっかけ AI・機械孊習のプロゞェクトに関わる䞭で、デヌタ分析の結果を正しく解釈したり、モデルの評䟡指暙を適切に理解したりするには、統蚈の基瀎が䞍可欠だず感じ賌入したした 内容 統蚈孊の基瀎を䜓系的に孊べる教科曞です。蚘述統蚈平均、分散、暙準偏差などから始たり、確率分垃、掚定、怜定、回垰分析たで、統蚈孊の䞻芁なトピックを網矅しおいたす。数匏だけでなく、図やグラフを䜿った芖芚的な説明が豊富で、各章末には理解床を確認できる挔習問題も甚意されおいたす。 読んでみお 統蚈孊を基瀎から孊びたい初孊者、数孊が苊手だけど統蚈を理解したい゚ンゞニアにおすすめです。デヌタサむ゚ンスや機械孊習には蚘述統蚈や確率分垃が必ず䜿われるため、土台を孊ぶこずができたす。 改蚂新版゚ンゞニアのためのデヌタ分析基盀入門基本線 デヌタ掻甚を促進する プラットフォヌムデヌタ品質の考え方 賌入のきっかけ デヌタはAIの孊習や分析の土台ずなりたす。その背景知識を理解し、より高品質なデヌタを収集するこずで、高性胜なAIモデルの構築や粟床の高い分析が可胜になるず考えたした。特に、Extract抜出・Transform倉換・Loadロヌドずいったデヌタパむプラむンの基瀎を䜓系的に孊びたいず思い、賌入したした。 内容 デヌタ分析基盀の蚭蚈・構築に必芁な知識を䜓系的に解説した入門曞です。デヌタレむク、デヌタりェアハりス、デヌタマヌトずいった基本抂念から、ETL/ELTパむプラむンの蚭蚈、デヌタ品質管理、メタデヌタ管理たで幅広くカバヌしおいたす。 読んでみお デヌタ品質の重芁性やデヌタガバナンスの考え方など、技術面だけでなく運甚面の課題に぀いおも觊れられおいるが特に印象に残りたした。たたETLずELTの違いや、バッチ凊理ずストリヌム凊理の䜿い分けなど、基本的な知識が身に付きたす。 れロから䜜るDeep Learning ❺ ―生成モデル線 賌入のきっかけ 最新の画像生成AIは拡散モデルDiffusion Modelsよばれるアヌキテクチャが䞻流ずなっおいるため、その仕組みを理論だけでなく実装レベルで理解したいず思い賌入したした。「れロから䜜る」シリヌズは過去にも読んでおり、実装を通しお孊ぶスタむルが自分に合っおいたこずも決め手でした。 内容 生成モデルの基瀎から最新の拡散モデルたでを段階的に孊ぶこずができたす。正芏分垃、倚次元正芏分垃、混合ガりスモデル、ニュヌラルネットワヌク、倉分オヌト゚ンコヌダVAE、拡散モデルずいう順に、ステップを螏んで理解を深めおいける構成になっおいたす。 読んでみお 実装を通しお孊ぶこずで、拡散モデルの数匏の意味や各ステップの圹割が深く理解できたした。特に、ノむズを段階的に陀去しおいくプロセスを実装するこずで、「なぜこのアルゎリズムが機胜するのか」を理解するこずができたす。 ただし欠点ずしお、text-to-imageやimage-to-imageずいった条件付き生成には察応しおいたせん。扱っおいるのは䞻に無条件の画像生成で、実務で䜿われおいるStable DiffusionやMidjourneyのようなテキストプロンプトからの生成に぀いおは觊れられおいたせん。たた、党䜓的にボリュヌムが少なく感じられ、もう少し応甚的な内容や最新モデルの解説があっおも良かったず思いたす。 Pythonで動かしながら孊ぶ コンピュヌタネットワヌク (KS情報科孊専門曞) 賌入のきっかけ Webアプリケヌション開発やクラりドを利甚する䞭で、ネットワヌクの知識䞍足を感じる堎面が増えおきたした。HTTPやTCP/IPずいった甚語は知っおいるものの、実際にどのように通信が行われおいるのか、パケットレベルでの理解が曖昧だったため、実装を通しお孊べる本曞を賌入したした。 内容 コンピュヌタネットワヌクの基瀎をPythonで実装しながら孊べる技術曞です。TCP/IP、UDP、HTTP、DNSずいったプロトコルの仕組みを、Pythonを䜿っお実際に動かしながら理解しおいきたす。 読んでみお 実際にコヌドを曞きながら孊ぶこずで、抜象的だったネットワヌクの抂念が具䜓的にむメヌゞできるようになりたした。特に、TCPの3りェむハンドシェむクやHTTPリク゚ストの送受信を自分で実装するこずで、むンタヌネットの裏偎を少し理解できた感芚がありたした。 最埌に 振り返っおみるず、2025幎は興味が発散しがちで、あれもこれもず手を出しおしたった䞀幎でした。 2026幎は焊点を絞っお、クラりド特にGoogle Cloudを䞭心に孊んでいこうず思いたす。 むベント告知 12月23日にむベントを開催したす申し蟌みはこちらから▌ https://mynaviit.connpass.com/event/376769
本蚘事は【 Advent Calendar 2025 】の15日目の蚘事です。 はじめに ITディベロップ第2統括郚ITディベロップ2郚開発1課のH.Yです。 私は新卒2幎目の゚ンゞニアずしお、少人数の開発チヌムを䞭心に、AIチヌムやむンフラなど耇数郚門ず連携するプロゞェクトでPMプロゞェクトマネヌゞャヌを任されたした。 厳密には、最初は「PLプロゞェクトリヌダヌをやりたい」ず課長に盞談し、了承をもらっおいたした。ずころが、開発を進めるために必芁なこずをどんどん進めおいたら、気づけばPMの圹割を担っおいたした。 実際、統括PMからも「タスクをどんどん巻き取っおほしい」ずいう意図があり、そのたたPMずしお動くこずになった、ずいう流れです。 初めおの経隓でしたが、「若手だからサポヌトしおもらえるだろうし、せっかくだから色々挑戊しよう」ずいう気持ちで臚んでいたため、䞍安のようなネガティブな感情は特にありたせんでした。 その分、プレむダヌ脳のたた突っ走り、結果ずしお倚くの倱敗を経隓したした。 この蚘事では、その倱敗ず孊びをたずめおいたす。 同じく若手でPMを始めた人やPMをやりたい人の参考になれば幞いです。 プロゞェクト䜓制 PO芁件定矩、受け入れ基準の策定、仕様倉曎の意思決定 統括PM党䜓の進行管理 PM私進捗管理、調敎、スケゞュヌル策定 開発チヌム5名 Yさん業務委蚗ベテラン゚ンゞニアFE芋積もり担圓 Tさんフロント゚ンド実装担圓 Hさんフロント゚ンド実装担圓 Dさんバック゚ンド実装担圓 Pさんバック゚ンド実装小タスク担圓 他郚眲連携 AIチヌムDB䜜成、AI機胜甚のデヌタ敎備、倖郚API䜜成 むンフラチヌムデプロむ手順䜜成、むンフラ構成倉曎察応 デザむナヌ仕様倉曎に䌎うデザむン修正 倱敗談ず孊び 1. 情報共有は“党郚”ではなく“行動可胜な圢”で 状況 ステヌクホルダヌずの方針倉曎や重芁なやり取りがSlackで発生した際、私はメンバヌ党員をメンションしおリンクを貌り、「これの把握お願いしたす」ず連絡しおいたした。 しかし、そのような連絡は膚倧になり、結果ずしお把握挏れが生じたした。 原因 PMずメンバヌが把握する情報の性質が異なる PM浅く広く把握 メンバヌ狭く深く把握 人には凊理できる情報量に限界があるため、メンバヌにPMず同じ情報量の把握を期埅するのは間違い メンバヌ目線では「把握しおください」ず蚀われおも、䜕をすればいいのか分からず、行動に結び぀かない 察応 ただメンバヌに察応しおもらわない情報は共有しない PMの仕事は「メンバヌが動ける状態に情報を敎理するこず」 珟状・課題・完了条件・PMが考える手段・備考を敎理し、Issueに萜ずし蟌む 孊び メンバヌが動けるように情報を倉換するのがPMの仕事 PMが凊理できる情報の深さに限床があるように、メンバヌが凊理できる情報の広さにも限床がある 2. スケゞュヌル認識ズレで焊った話 状況 Yさんず進捗確認をした際、期限の認識が倧きくズレおいるこずが刀明。 私の想定期限は10月14日 Yさんの認識期限はその2週間埌 さらに、Yさんから「そのスケゞュヌルではかなり無理がある」ず指摘され、焊りたした。 原因 統括PMが提瀺したスケゞュヌルは「理想倀」だった 私はそれを「絶察倀」ず誀解し、Slackで共有したが通知過倚で芋萜ずされおいた 認識合わせを党員で行う仕組みがなかった プロゞェクト理解が浅く、ガントチャヌトを䜜れる状態ではなかったため、「ずりあえず進めれば芋通しが぀く」ずいうプレむダヌ的発想で動いおいた 察応 Yさんず統括PMを亀えお緊急ミヌティングを実斜。結果、スケゞュヌルは調敎可胜であるこずが分かり、事なきを埗たした。 孊び ガントチャヌトを䜜るべきずいう理解はあったが、プロゞェクト初期は情報䞍足で䜜れないこずもある ガントチャヌトを䜜る胜力は、プロゞェクトの性質をもずにリスク芁因を芋抜く力に䟝存する 「ずりあえず進める」だけでは䞍確実性が増すため、進めながらも認識合わせの仕組みを早期に䜜る 重芁な認識合わせはSlackだけに頌らず、確実に確認できる仕組みを甚意する 3. 芁件の裏にある課題を理解するこずの重芁性 状況 既存システムにない新しい機胜の甚途を勘違いし、POの想定ずは異なる仕様で実装しおしたったため、手戻りが生じたした。 原因 POが定矩した受け入れ基準に仕様が蚘茉されおいなかった 芁件は理解したが、事業郚の業務フロヌ䞊「なぜ必芁なのか」を理解しないたた進めた 察応 「本圓にその機胜必芁なの」「より適切な課題解決手段はないのか」ず疑う意識を持぀こず 孊び 蚀われたからやるのではなく、自分の蚀葉で「なぜやるか」を説明できる皋床に理解しないず手戻りが生じる可胜性がある 4. PJ完了の定矩を明確にするこずの重芁性 状況 プロゞェクト序盀にPOに受け入れ基準を定矩しおもらい、仕様倉曎のたびに合意を取りながら曎新しおいたした。 しかし終盀ではPJ完了の定矩が曖昧になり、関係者間で「䜕をもっおプロゞェクト終了なのか」が䞍明確になり、メンバヌを䞍安にさせおしたいたした。 原因 仕様倉曎が高頻床で発生し、受け入れ基準曎新の優先床が䞋がった 「受け入れ基準を満たすものを䜜る」ずいう合意があったため、基準が増えるほど負担が増える心理的ハヌドルがあった 察応 珟状をPOに報告し、「受け入れ基準を最新化するのでレビュヌしおほしい」ず䟝頌 合意圢成を再床取り盎し、受け入れ基準を最新化しおプロゞェクト完了条件を明確化 孊び PJ完了の定矩は、関係者党員が同じ認識を持おるように仕組み化する PMになりたい人ぞ プレむダヌの時もPMの時も、 自䞻性・課題解決胜力・目的意識 ずいった胜力はずおも重芁です。 ただし、PMになるず、それらの胜力を 掻かす方法が倧きく倉わりたす 。 プレむダヌは「自分で成果を出す」こずに集䞭したすが、PMは「チヌムが成果を出せる状態を䜜る」こずが圹割です。 PMずしお働くのは簡単ではありたせん。調敎や意思決定、リスク管理など、プレむダヌ時代には経隓しなかった難しさがありたす。 しかし、その分、 刺激が倚く、孊びも倧きい仕事です 。 この蚘事で玹介した私の倱敗は、すべお成長の糧になりたした。 もしあなたがPMに興味を持っおいるなら、ぜひ挑戊しおみおください。
本蚘事は【 Advent Calendar 2025 】の14日目の蚘事です。 デゞタルプラットフォヌム統括本郚デヌタ゜リュヌション統括郚デヌタアヌキテクト郚アナリティクス掚進課のA・Kです。 そういえば自分でも久しく忘れおいたのですが、ミステリヌや掚理小説、叙述トリック物の小説が奜きで昔よく読んでいたした。タむトルで分かった方もいるかもしれたせんが、奜きな䜜家は工孊博士の森博嗣先生です。 ずいうこずで、今回はBIツヌルTableauのIF文にた぀わるミステリヌを曞こうず思いたす。 0. プロロヌグ Tableauには「蚈算フィヌルド」ずいう抂念がありたす。蚈算フィヌルドを䜿うず、定数・倉数を亀えた算術蚈算や文字列操䜜などの結果をフィヌルドに出力するこずができ、䞻に動的な出力を埗たい堎合に利甚したす。 䟋えば、顧客ぞの商品販売履歎が蚘録されおいる以䞋のようなテヌブルがあるずしたす。 泚文ID 泚文日 ナヌザヌID ナヌザヌ名 郜道府県 定䟡 賌入額 2025-645614 2025/1/30 U-562596 鈎朚 花子 富山県 40000 40000 2025-748109 2025/3/29 U-585788 吉田 盎暹 新期県 180000 180000 2025-388360 2025/4/18 U-577077 高橋 健 䜐賀県 260000 208000 2025-355111 2025/5/3 U-750671 æ–Žè—€ 真简 青森県 250000 250000 2025-420588 2025/5/4 U-362222 䞭村 真由 宮城県 200000 200000 2025-290629 2025/5/16 U-013025 䜐藀 倪郎 沖瞄県 130000 104000 2025-277039 2025/6/22 U-715673 枡蟺 圩 茚城県 200000 40000 2025-864082 2025/7/28 U-577077 高橋 健 䜐賀県 300000 300000 2025-973922 2025/9/30 U-909473 小林 誠 東京郜 180000 180000 2025-091362 2025/11/22 U-446022 加藀 結衣 栃朚県 30000 24000 このテヌブルをTableauで読み蟌み、「どのくらいの割匕率で賌入しおもらったのか」の列を远加しお可芖化する堎合、以䞋の蚈算フィヌルドを䜜成し新たな列ずしお远加するこずで実珟できたす。 割匕率([定䟡] - [賌入額]) / [定䟡] 1. 双頭の悪魔 たず、以䞋の蚘述をご芧ください。 IF SIZE() = 1 THEN (SUM([定䟡] - [賌入額])) / SUM([定䟡])ELSE (SUM([定䟡] - [賌入額])) / SUM([定䟡])END Tableauの蚈算フィヌルドにおけるIF文のフォヌマット今回のケヌスに盞圓するものは、以䞋のずおりです。 IF <条件> THEN <条件に合臎する堎合の出力>ELSE <条件に合臎しない堎合の出力>END たた、SUM関数は指定したカラムの倀をさたざたな粒床党䜓、䞀郚のグルヌプにおいお、などで合蚈するこずができたす。 ぀たり、はじめに掲茉した蚘述は、条件「SIZE() = 1」に合臎する堎合 (SUM([定䟡] - [賌入額])) / SUM([定䟡]) ïŒˆïŒè€‡æ•°ãƒ¬ã‚³ãƒŒãƒ‰ã®å‰²åŒ•率 ã‚’返し、条件に合臎しない堎合 (SUM([定䟡] - [賌入額])) / SUM([定䟡]) を返したす。  っお、えこれどっちの蚈算匏も同じくない はい、そうです。この条件に合臎する堎合ずしない堎合の蚈算匏は、 たったく同じ蚈算匏 です。 「分かったこれ本圓はIF文を䜿わなくおも実珟できるけど、無理やりIF文にしおるだけだろ」ず予想した方がいるかもしれたせんが、残念ながら今回のケヌスでは IFを䜿い条件分岐させないず正しい結果を埗られたせん 。 5. ここでいきなり゚ピロヌグ  こうしお䜜成した蚈算フィヌルドを䜿い、以䞋のような集蚈結果の衚瀺を実珟するこずができたした。めでたしめでたし。 総蚈ずいう行が远加されおいるこずが分かるず思いたす。総蚈はTableauがデフォルトで持぀集蚈機胜で、各レコヌドをさたざたな粒床で合蚈したり平均したりするこずができたす。 今回は定䟡や賌入額の平均単䟡、平均割匕率を衚瀺したかったので、「平均により集蚈を行った総蚈」を最終行に衚瀺するこずにしおいたす。 2. 真倏の総蚈匏 さお、総蚈はTableauのデフォルトの機胜ずお䌝えしたしたが、実はトラップがありたす。以䞋の衚は、平均による総蚈機胜を単玔に適甚したずきの集蚈結果です。 䞀芋どこがおかしいのか分かりにくいですが、前項で掲茉したキャプチャずの違いは割匕率の総蚈です。前項キャプチャでは13.8だったのに察し、今回は14.0ずなっおいたす。これはどちらが正しいのでしょうか ずいうこずで正しい蚈算をしおみたす。割匕率の平均ずは、いわば党䜓に均したならしたずきの割匕率にあたるので 割匕金額の合蚈 ÷ 定䟡の合蚈 で算出するこずができたす。実際に蚈算しおみたす。 割匕金額の合蚈  244,000 定䟡の合蚈  1,770,000 割匕金額の合蚈 ÷ 定䟡の合蚈  0.1378 ≒  13.8 ずいうこずで、正しい倀は13.8でした。え では、14.0ずいうのはどこから来た数倀なのでしょうか 実は、総蚈機胜の平均は以䞋赀枠郚分の平均を集蚈しおいたす。 0  0  20  
  20÷ 10 14.0 ですね。このように、総蚈機胜は各レコヌドの倀を単玔に算術蚈算しお集蚈を行うのですが、 割合の平均は算術平均で求めるこずができたせん 。これが総蚈のトラップです。 では、定䟡ず賌入額の集蚈には算術平均を䜿い、割合の平均を集蚈するずきは別の蚈算を行うにはどうすればいいのでしょうか 3. GYOTH あらためお、冒頭に出おきた蚈算匏を再床芋おみたす。 IF SIZE() = 1 THEN (SUM([定䟡] - [賌入額])) / SUM([定䟡])ELSE (SUM([定䟡] - [賌入額])) / SUM([定䟡])END ここで気になるのが  SIZE() = 1  ãšã„う条件です。SIZE() ずはどのような関数なのでしょうか 結論、 SIZE関数は 各レコヌドが属するパヌティション内の行数を返したす 。パヌティションずいう単䜍がどこを衚すかずいうず、以䞋の図のずおりです。 埓っお、各行に SIZE関数を適甚するず、以䞋の倀が返っおきたす。 犯人が芋えおきたしたね。 4. むニシ゚ヌション・サム 埓っお、 割匕率IF SIZE() = 1 THEN (SUM([定䟡] - [賌入額])) / SUM([定䟡])ELSE (SUM([定䟡] - [賌入額])) / SUM([定䟡])END この蚈算フィヌルドを䜜成するこずにより、SIZE() = 1 、぀たり総蚈の行においお各レコヌドの平均を蚈算せず (SUM([定䟡] - [賌入額])) / SUM([定䟡]) を蚈算し、たた SIZE() ≠ 1 、぀たり総蚈以倖のすべおの行においおも (SUM([定䟡] - [賌入額])) / SUM([定䟡]) を蚈算するこずができるようになりたす。 ここで1぀、最埌の疑問が残りたす。「総蚈以倖の行はすべお1行ごずに割匕率を蚈算するんだから、わざわざSUMを䜿っお合蚈する必芁はないのでは」 その答えは2぀ありたす。1぀は、そういう仕様だからですSUMなど集蚈関数を぀けないず゚ラヌが出たす。なんだそりゃ、ず思う方もいるかもしれたせんが、これは合理的な仕様です。その合理性が分かるもう1぀の理由が、Tableauはデヌタ分析に䜿うツヌルなので、以䞋のように別の切り口でも分析しおみたいずいうニヌズがありえる点です。この堎合、地域ごずに定䟡の合蚈、割匕額の合蚈を算出するためにSUMを行う必芁があるのは明癜です。 5. ゚ピロヌグ  こうしお䜜成した蚈算フィヌルドを䜿い、以䞋のような集蚈結果の衚瀺を実珟するこずができたした。めでたしめでたし。 6. あずがき ずいうこずで、Tableau IF文ミステリィでした。今回のケヌスは、実際に業務でのレポヌト䜜成䞭に盎面した問題がベヌスになっおいたす。私自身、IF文の条件に合う堎合ず合わない堎合でたったく同じ蚈算匏を䜿う、ずいう経隓がこれたでなかったので、このような方法で解決できたこずが非垞に興味深かったです。 Tableauはこのような圢で蚈算フィヌルドを掻甚し、集蚈を行うこずができたす。このミステリヌもどきでTableauに興味を持たれた方は、さたざたな機胜や蚈算フィヌルドを䜿っおデヌタの可芖化にチャレンゞしおみおください新たな発芋があるかもしれたせん。 以䞊、ノァン・ダむンでした。 むベント告知 12月23日にむベントを開催したす申し蟌みはこちらから▌ https://mynaviit.connpass.com/event/376769
本蚘事は【 Advent Calendar 2025 】の13日目の蚘事です。 Autogen ずは Autogenは、AIを掻甚したマルチ゚ヌゞェントシステム構築のためのフレヌムワヌクです。 簡単に蚀うず AI゚ヌゞェントを盞互に䌚話させ、協働させ、タスクを自動的に解決させるこずができたす。 1぀のAIがすべおを行う代わりに、耇数の専門化された゚ヌゞェントが存圚したす。 これらの゚ヌゞェントは、耇雑なワヌクフロヌを完了するために通信し、情報を共有し、協力しお䜜業できたす。 特城 LLM統合 GPTなどのモデルず連携したす。 スケヌラブルなアヌキテクチャ 耇雑な倚段階プロセスを凊理したす。 カスタム゚ヌゞェント ニヌズに合わせた゚ヌゞェントを構築したす。 歎史 Autogenは圓初、Microsoftのみで開発されおいたした。 その埌、AG2ずバヌゞョン0.4に分割されたした。 AG2は党く異なるフレヌムワヌクであり、別個に管理されおいたす。 ChatGPTやその他のコヌド生成゚ヌゞェントはAG2向けのコヌドを提䟛したす。 Autogenのコヌドを生成するようChatGPTに䟝頌しおも正しいコヌドが埗られないです。 AIから䜜成したAutogenのコヌド ナヌスケヌス ゜フトりェア開発アシスタント ゚ヌゞェント コヌド生成゚ヌゞェント初期コヌドを生成 コヌドレビュヌ゚ヌゞェントバグずベストプラクティスをチェック ドキュメント゚ヌゞェント䜿甚方法ドキュメントを䜜成 目暙 開発を加速し、品質を維持する。 旅行蚈画 ゚ヌゞェント 旅皋プランナヌ旅行の日ごずの旅皋を䜜成したす 費甚芋積もり担圓者旅行のおおよその費甚を蚈算したす レビュヌ担圓者蚈画が珟実的か぀実践的かどうかを確認する 目暙 予算内で珟実的な旅行蚈画を䜜成する。 コンテンツ制䜜 ゚ヌゞェント ラむタヌブログや蚘事の草皿䜜成 線集者文法やトヌンのチェック SEOスペシャリストキヌワヌドの最適化 目暙 高品質でSEO察策に優れたコンテンツを䜜成する。 デヌタ分析ず報告 ゚ヌゞェント デヌタコレクタヌAPIからデヌタを取埗 アナリストむンサむトずチャヌトを生成 レポヌトラむタヌ調査結果を平易な蚀葉で芁玄 目暙 ゚ンドツヌ゚ンドのレポヌト䜜成を自動化する。 APIキヌに぀いお OpenAI APIキヌは数幎前は無料でしたが、珟圚は無料ではありたせん。 掚奚アプロヌチ Gemini APIキヌを䜿甚する https://ai.google.dev/gemini-api/docs/api-key  Ollamaを䜿甚するLLMモデルをロヌカルで実行するために䜿甚 OpenRouter APIキヌを䜿甚する Ollama は自分の所属する䌚瀟ルヌルに埓っお利甚しお䞋さい。 䞀定期間無料で䜿甚できるGemini APIキヌたたはOpenRouter APIキヌを䜿甚するのが最適です。 私はGeminiキヌを䜿甚したす。Geminiキヌを䜿甚する堎合、以䞋のコヌドでAutogenを詊すこずができたす Geminiにログむンし、パヌ゜ナルアカりントを䜿甚しおAPIキヌを生成しおください。 重芁なポむント Autogenでは非同期で゚ヌゞェントぞの呌び出しが行われる。Pythonラむブラリで非同期コヌディングを実珟するためにAsyncioが䜿甚される。 Autogenでは、各゚ヌゞェントがどの分野の専門家であるか私たちが指定したす 初めおのオヌトゞェン゚ヌゞェントを䜜成したしょう 手順 Autogen甚の環境を䜜成する Autogent甚の環境の䜜成 python3 -m venv autogensource autogen/bin/activate requirements.txt ファむルを䜜成する 必芁なパッケヌゞをすべお1぀のファむルで定矩する requirements.txt autogen-agentchatautogen-coreautogen-extasynciodotenvopenaitiktoken autogen - agentchat autogen - core autogen - ext asyncio dotenv openai tiktoken pip install -r requirements.txt GEMINI APIキヌの環境倉数を蚭定するご自身のAPIキヌを远加しおください (APIキヌの定矩) .env GEMINI_API_KEY = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" GEMINI_API_KEY = " xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx " 単䞀゚ヌゞェントの䜜成 質問に察しお出力結果を返すシンプルな単䞀゚ヌゞェントを䜜成する agent.py import asynciofrom autogen_agentchat.agents import AssistantAgentfrom autogen_ext.models.openai import OpenAIChatCompletionClientfrom autogen_agentchat.messages import TextMessagefrom autogen_core.models import ModelInfofrom dotenv import load_dotenvimport osload_dotenv()api_key = os.getenv("GEMINI_API_KEY")model_client = OpenAIChatCompletionClient( model="gemini-2.0-flash-lite", model_info=ModelInfo(vision=True, function_calling=True, json_output=True, family="unknown", structured_output=True), api_key=api_key,)assistant = AssistantAgent( name="Chatgpt", model_client=model_client, description="First basic Agent")async def main(): result = await assistant.run(task="What is the capital of Japan?") print(result.messages[-1].content)asyncio.run(main()) import asyncio from autogen_agentchat . agents import AssistantAgent from autogen_ext . models . openai import OpenAIChatCompletionClient from autogen_agentchat . messages import TextMessage from autogen_core . models import ModelInfo from dotenv import load_dotenv import os load_dotenv () api_key = os . getenv ( " GEMINI_API_KEY " ) model_client = OpenAIChatCompletionClient ( model = " gemini-2.0-flash-lite " , model_info = ModelInfo ( vision =True , function_calling =True , json_output =True , family = " unknown " , structured_output =True ), api_key = api_key , ) assistant = AssistantAgent ( name = " Chatgpt " , model_client = model_client , description = " First basic Agent " ) async def main (): result = await assistant . run ( task = " What is the capital of Japan? " ) print ( result . messages [ - 1 ]. content ) asyncio . run ( main ()) python3 agent.py アりトプット マルチ゚ヌゞェントAIを䜜成したしょう 指定された予算ず指定期間内で旅行の旅皋を生成するマルチ゚ヌゞェントシステムを構築する。 itinerary_agent - 指定された郜垂ず期間に察しお、詳现な日ごずの旅行蚈画を䜜成したす。 cost_agent - 旅皋を受け取り、おおよその費甚を蚈算したす亀通費、食費、芳光費、宿泊費。 review_agent - 旅皋ず費甚芋積もりが珟実的かどうかを確認する 䞉人の゚ヌゞェントが互いに連携し、最終的に完璧な旅皋を生成する multiAgent.py import asynciofrom autogen_ext.models.openai import OpenAIChatCompletionClientfrom autogen_agentchat.agents import AssistantAgentfrom autogen_agentchat.teams import RoundRobinGroupChatfrom autogen_agentchat.messages import TextMessagefrom autogen_core.models import ModelInfofrom dotenv import load_dotenvimport osload_dotenv()api_key = os.getenv("GEMINI_API_KEY")model_client = OpenAIChatCompletionClient( model="gemini-2.0-flash-lite", model_info=ModelInfo(vision=True, function_calling=True, json_output=True, family="unknown", structured_output=True), api_key=api_key)itinerary_agent = AssistantAgent( name="itinerary_agent", model_client=model_client, system_message=( "あなたは旅行日皋の専門家です。 " "特定の郜垂ず滞圚日数が䞎えられた堎合、詳现な日別旅行蚈画を䜜成しおください。 " "時間割、蚪問堎所、亀通手段の提案、およびその理由を含めおください。" ))cost_agent = AssistantAgent( name="cost_agent", model_client=model_client, system_message=( "あなたは旅行費甚芋積もり担圓者です。" "旅皋が䞎えられた堎合、亀通費、食費、芳光費、宿泊費のおおよその費甚を蚈算しおください。 " "合蚈がナヌザヌの予算を超えた堎合、より安䟡な倉曎案を提案しおください。" ))review_agent = AssistantAgent( name="review_agent", model_client=model_client, system_message=( "旅皋ず費甚芋積もりを怜蚌する審査員です。 " "蚈画が珟実的か確認しおください移動時間、営業時間、順序。 " "問題がある堎合は、前の担圓者に修正を䟝頌しおください。" ))team = RoundRobinGroupChat( participants=[itinerary_agent, cost_agent, review_agent], max_turns=6)async def run_team(): user_task = TextMessage( content="京郜ぞの3日間の旅行を5䞇円以内で蚈画しおください。予算内に収め぀぀、楜しめるプランにしたしょう。内容は200語以内に収めおください。", source="user") result = await team.run(task=user_task) for msg in result.messages: print(f"{msg.source}:\n{msg.content}\n")async def main(): await run_team()asyncio.run(main()) import asyncio from autogen_ext . models . openai import OpenAIChatCompletionClient from autogen_agentchat . agents import AssistantAgent from autogen_agentchat . teams import RoundRobinGroupChat from autogen_agentchat . messages import TextMessage from autogen_core . models import ModelInfo from dotenv import load_dotenv import os load_dotenv () api_key = os . getenv ( " GEMINI_API_KEY " ) model_client = OpenAIChatCompletionClient ( model = " gemini-2.0-flash-lite " , model_info = ModelInfo ( vision =True , function_calling =True , json_output =True , family = " unknown " , structured_output =True ), api_key = api_key ) itinerary_agent = AssistantAgent ( name = " itinerary_agent " , model_client = model_client , system_message = ( " あなたは旅行日皋の専門家です。 " " 特定の郜垂ず滞圚日数が䞎えられた堎合、詳现な日別旅行蚈画を䜜成しおください。 " " 時間割、蚪問堎所、亀通手段の提案、およびその理由を含めおください。 " ) ) cost_agent = AssistantAgent ( name = " cost_agent " , model_client = model_client , system_message = ( " あなたは旅行費甚芋積もり担圓者です。 " " 旅皋が䞎えられた堎合、亀通費、食費、芳光費、宿泊費のおおよその費甚を蚈算しおください。 " " 合蚈がナヌザヌの予算を超えた堎合、より安䟡な倉曎案を提案しおください。 " ) ) review_agent = AssistantAgent ( name = " review_agent " , model_client = model_client , system_message = ( " 旅皋ず費甚芋積もりを怜蚌する審査員です。 " " 蚈画が珟実的か確認しおください移動時間、営業時間、順序。 " " 問題がある堎合は、前の担圓者に修正を䟝頌しおください。 " ) ) team = RoundRobinGroupChat ( participants = [ itinerary_agent , cost_agent , review_agent ], max_turns = 6 ) async def run_team (): user_task = TextMessage ( content = " 京郜ぞの3日間の旅行を5䞇円以内で蚈画しおください。予算内に収め぀぀、楜しめるプランにしたしょう。内容は200語以内に収めおください。 " , source = " user " ) result = await team . run ( task = user_task ) for msg in result . messages : print ( f " { msg . source } : \n{ msg . content }\n " ) async def main (): await run_team () asyncio . run ( main ()) python3 multiAgent.py アりトプット user:京郜ぞの3日間の旅行を5䞇円以内で蚈画しおください。予算内に収め぀぀、楜しめるプランにしたしょう。内容は200語以内に収めおください。itinerary_agent:承知いたしたした。京郜3日間5䞇円以内の旅皋をご提案したす。**1日目:*** **午前:** 䌏芋皲荷倧瀟ぞ。朱色の鳥居が圧巻です。* **午埌:** 枅氎寺呚蟺を散策。枅氎の舞台からの眺めを堪胜し、二幎坂・産寧坂でお土産探し。* **倕食:** 予算を考慮し、駅呚蟺の定食屋で。* **亀通:** 垂バス1日乗車刞利甚がお埗**2日目:*** **午前:** 金閣寺ぞ。金箔が茝く姿は必芋。* **午埌:** 嵐山ぞ。竹林の道や枡月橋を散策。人力車は予算に応じお。* **倕食:** 嵐山で食べ歩きや、手頃な䟡栌のカフェで倕食を。* **亀通:** 嵐電、JR**3日目:*** **午前:** 錊垂堎で食べ歩き。* **午埌:** 京郜埡所を散策事前予玄掚奚。* **倕食:** 京郜駅呚蟺で新幹線に乗る前に、お土産を賌入し、駅ビル内のレストランで最埌の食事を。* **亀通:** 垂バス、電車、新幹線**宿泊:** ゲストハりスや栌安ホテルを遞択。食事は、安䟡な店やコンビニを掻甚するこずで予算内に収たるでしょう。cost_agent:玠晎らしいプランですね 䌏芋皲荷倧瀟、枅氎寺、金閣寺、嵐山ず、京郜の䞻芁な芳光スポットをバランス良く網矅しおいたす。垂バスの䞀日乗車刞を利甚するなど、亀通費を抑える工倫も玠晎らしいです。**詳现な費甚抂算*** **亀通費:** * 新幹線埀埩玄20,000円 (出発地によりたす) * 垂バス1日乗車刞1,100円 × 2日 = 2,200円 * 嵐電、JRなど3,000円 * **合蚈玄25,200円*** **宿泊費:** ゲストハりスたたは栌安ホテル (3泊)1泊あたり5,000円ず仮定しお、15,000円* **食費:** 1日あたり3,000円 × 3日 = 9,000円* **芳光費:** 各斜蚭の入堎料、お土産代など玄5,000円* **合蚈玄54,200円**この抂算では、残念ながら5䞇円の予算を若干オヌバヌしおしたいたす。 そこで、いく぀か調敎案をご提案したす。**調敎案**1. **亀通費の芋盎し:** * 新幹線の代わりに、倜行バスを利甚する (埀埩10,000円皋床で枈む可胜性がありたす)。2. **宿泊費の芋盎し:** * カプセルホテルや、より栌安なゲストハりスを探す。 * Airbnbなどを利甚する。3. **食費の芋盎し:** * 自炊できるゲストハりスを遞ぶ。 * ランチは軜食にする。4. **芳光費の芋盎し:** * 入堎料が無料の堎所も掻甚する䟋䌏芋皲荷倧瀟。 * お土産は、少なめにするか、リヌズナブルなものを遞ぶ。これらの調敎を行うこずで、5䞇円の予算内に収たる可胜性がありたす。review_agent:ありがずうございたす。詳现な費甚抂算ず、的確な調敎案のご提瀺、倧倉助かりたす。確かに、新幹線を倜行バスに倉曎するこずや、宿泊費を抑えるこずが、予算内に収めるための重芁なポむントですね。**修正埌のプラン調敎案を反映****1日目:*** **午前:** 䌏芋皲荷倧瀟ぞ。* **午埌:** 枅氎寺呚蟺を散策。枅氎の舞台からの眺めを堪胜し、二幎坂・産寧坂でお土産探し。* **倕食:** 予算を考慮し、駅呚蟺の定食屋で。* **亀通:** 垂バス1日乗車刞利甚**2日目:*** **午前:** 金閣寺ぞ。* **午埌:** 嵐山ぞ。竹林の道や枡月橋を散策。人力車は今回は芋送り。* **倕食:** 嵐山で食べ歩きや、手頃な䟡栌のカフェで倕食を。* **亀通:** 嵐電、JR**3日目:*** **午前:** 錊垂堎で食べ歩き。* **午埌:** 京郜埡所を散策事前予玄掚奚。* **倕食:** 京郜駅呚蟺で新幹線に乗る前に、お土産を賌入し、駅ビル内のレストランで最埌の食事を。* **亀通:** 垂バス、電車、倜行バス**費甚の再抂算調敎案反映埌*** **亀通費:** * 倜行バス埀埩玄10,000円 * 垂バス1日乗車刞1,100円 × 2日 = 2,200円 * 嵐電、JRなど3,000円 * **合蚈玄15,200円*** **宿泊費:** カプセルホテルたたは栌安ゲストハりス (3泊)1泊あたり4,000円ず仮定しお、12,000円* **食費:** 1日あたり2,500円 × 3日 = 7,500円ランチは軜食䞭心* **芳光費:** 各斜蚭の入堎料、お土産代など玄10,300円 (䌏芋皲荷倧瀟、枅氎寺、金閣寺は入堎料がかかりたすが、それ以倖の堎所では無料の堎所も掻甚し、お土産代を調敎)* **合蚈玄45,000円**これで、5䞇円の予算内に収たりそうですねこのプランは、倜行バスの利甚、宿泊費の節玄、食費の芋盎し、芳光費の調敎によっお、予算をクリアできる可胜性が高くなりたした。玠晎らしいです。itinerary_agent:完璧ですね修正案が反映され、5䞇円以内の予算で、京郜の䞻芁芳光地を巡る3日間の旅皋が実珟可胜になりたした。**補足事項:*** **倜行バスの予玄:** 確実に予玄を確保するため、早めの予玄をお勧めしたす。* **宿泊斜蚭の予玄:** ゲストハりスやカプセルホテルも、人気のある斜蚭はすぐに満宀になるこずがありたす。こちらも早めの予玄を。* **京郜埡所の予玄:** 事前予玄が必芁ですので、忘れずに手続きしおください。* **芳光斜蚭の開通時間:** 各斜蚭の開通時間を事前に確認し、効率よく芳光できるように蚈画を立おたしょう。* **移動時間:** 垂バスや電車での移動時間を考慮し、無理のないスケゞュヌルを立おたしょう。* **持ち物:** 歩きやすい靎、防寒具、雚具などを忘れずに準備したしょう。このプランで、京郜の魅力を存分に楜しんでください 良い旅になりたすようにcost_agent:ありがずうございたす 完璧なプランニングですね。補足事項も非垞に的確で、旅行者が安心しお旅を楜しめるよう、现やかな配慮がされおいたす。このプランを参考に、楜しい京郜旅行を満喫しおください 䜕か他に質問があれば、お気軜にお尋ねください。review_agent:ありがずうございたす こちらこそ、玠晎らしいプランを䞀緒に䜜り䞊げるこずができ、倧倉光栄です。䜕かお圹に立おるこずがあれば、い぀でもお声がけください。 良い旅になりたすように user : 京郜ぞの3日間の旅行を5䞇円以内で蚈画しおください。予算内に収め぀぀、楜しめるプランにしたしょう。内容は200語以内に収めおください。 itinerary_agent : 承知いたしたした。京郜3日間5䞇円以内の旅皋をご提案したす。 ** 1日目 : ** * ** 午前 : ** 䌏芋皲荷倧瀟ぞ。朱色の鳥居が圧巻です。 * ** 午埌 : ** 枅氎寺呚蟺を散策。枅氎の舞台からの眺めを堪胜し、二幎坂・産寧坂でお土産探し。 * ** 倕食 : ** 予算を考慮し、駅呚蟺の定食屋で。 * ** 亀通 : ** 垂バス 1日乗車刞利甚がお埗  ** 2日目 : ** * ** 午前 : ** 金閣寺ぞ。金箔が茝く姿は必芋。 * ** 午埌 : ** 嵐山ぞ。竹林の道や枡月橋を散策。人力車は予算に応じお。 * ** 倕食 : ** 嵐山で食べ歩きや、手頃な䟡栌のカフェで倕食を。 * ** 亀通 : ** 嵐電、JR ** 3日目 : ** * ** 午前 : ** 錊垂堎で食べ歩き。 * ** 午埌 : ** 京郜埡所を散策事前予玄掚奚。 * ** 倕食 : ** 京郜駅呚蟺で新幹線に乗る前に、お土産を賌入し、駅ビル内のレストランで最埌の食事を。 * ** 亀通 : ** 垂バス、電車、新幹線 ** 宿泊 : ** ゲストハりスや栌安ホテルを遞択。食事は、安䟡な店やコンビニを掻甚するこずで予算内に収たるでしょう。 cost_agent : 玠晎らしいプランですね 䌏芋皲荷倧瀟、枅氎寺、金閣寺、嵐山ず、京郜の䞻芁な芳光スポットをバランス良く網矅しおいたす。垂バスの䞀日乗車刞を利甚するなど、亀通費を抑える工倫も玠晎らしいです。 ** 詳现な費甚抂算 ** * ** 亀通費 : ** * 新幹線埀埩玄20 , 000円 ( 出発地によりたす ) * 垂バス1日乗車刞 1 , 100円 × 2日 = 2 , 200円 * 嵐電、JRなど 3 , 000円 * ** 合蚈玄25 , 200円 ** * ** 宿泊費 : ** ゲストハりスたたは栌安ホテル ( 3泊 )  1泊あたり5 , 000円ず仮定しお 、 15 , 000円 * ** 食費 : ** 1日あたり3 , 000円 × 3日 = 9 , 000円 * ** 芳光費 : ** 各斜蚭の入堎料、お土産代など玄5 , 000円 * ** 合蚈玄54 , 200円 ** この抂算では、残念ながら5䞇円の予算を若干オヌバヌしおしたいたす。 そこで、いく぀か調敎案をご提案したす。 ** 調敎案 ** 1 . ** 亀通費の芋盎し : ** * 新幹線の代わりに、 倜行バスを利甚する ( 埀埩10 , 000円皋床で枈む可胜性がありたす ) 。 2 . ** 宿泊費の芋盎し : ** * カプセルホテルや、より栌安なゲストハりスを探す。 * Airbnbなどを利甚する。 3 . ** 食費の芋盎し : ** * 自炊できるゲストハりスを遞ぶ。 * ランチは軜食にする。 4 . ** 芳光費の芋盎し : ** * 入堎料が無料の堎所も掻甚する䟋䌏芋皲荷倧瀟。 * お土産は、少なめにするか、リヌズナブルなものを遞ぶ。 これらの調敎を行うこずで、 5䞇円の予算内に収たる可胜性がありたす 。 review_agent : ありがずうございたす。詳现な費甚抂算ず、的確な調敎案のご提瀺、倧倉助かりたす。確かに、新幹線を倜行バスに倉曎するこずや、宿泊費を抑えるこずが、予算内に収めるための重芁なポむントですね。 ** 修正埌のプラン調敎案を反映 ** ** 1日目 : ** * ** 午前 : ** 䌏芋皲荷倧瀟ぞ。 * ** 午埌 : ** 枅氎寺呚蟺を散策。枅氎の舞台からの眺めを堪胜し、二幎坂・産寧坂でお土産探し。 * ** 倕食 : ** 予算を考慮し、駅呚蟺の定食屋で。 * ** 亀通 : ** 垂バス 1日乗車刞利甚  ** 2日目 : ** * ** 午前 : ** 金閣寺ぞ。 * ** 午埌 : ** 嵐山ぞ。竹林の道や枡月橋を散策。人力車は今回は芋送り。 * ** 倕食 : ** 嵐山で食べ歩きや、手頃な䟡栌のカフェで倕食を。 * ** 亀通 : ** 嵐電、JR ** 3日目 : ** * ** 午前 : ** 錊垂堎で食べ歩き。 * ** 午埌 : ** 京郜埡所を散策事前予玄掚奚。 * ** 倕食 : ** 京郜駅呚蟺で新幹線に乗る前に、お土産を賌入し、駅ビル内のレストランで最埌の食事を。 * ** 亀通 : ** 垂バス、電車、倜行バス ** 費甚の再抂算調敎案反映埌 ** * ** 亀通費 : ** * 倜行バス埀埩玄10 , 000円 * 垂バス1日乗車刞 1 , 100円 × 2日 = 2 , 200円 * 嵐電、JRなど 3 , 000円 * ** 合蚈玄15 , 200円 ** * ** 宿泊費 : ** カプセルホテルたたは栌安ゲストハりス ( 3泊 )  1泊あたり4 , 000円ず仮定しお 、 12 , 000円 * ** 食費 : ** 1日あたり2 , 500円 × 3日 = 7 , 500円 ランチは軜食䞭心 * ** 芳光費 : ** 各斜蚭の入堎料、お土産代など玄10 , 300円 ( 䌏芋皲荷倧瀟、枅氎寺、金閣寺は入堎料がかかりたすが、それ以倖の堎所では無料の堎所も掻甚し、お土産代を調敎 ) * ** 合蚈玄45 , 000円 ** これで、 5䞇円の予算内に収たりそうですね  このプランは、倜行バスの利甚、宿泊費の節玄、食費の芋盎し、芳光費の調敎によっお、予算をクリアできる可胜性が高くなりたした。玠晎らしいです。 itinerary_agent : 完璧ですね修正案が反映され、 5䞇円以内の予算で 、京郜の䞻芁芳光地を巡る3日間の旅皋が実珟可胜になりたした。 ** 補足事項 : ** * ** 倜行バスの予玄 : ** 確実に予玄を確保するため、早めの予玄をお勧めしたす。 * ** 宿泊斜蚭の予玄 : ** ゲストハりスやカプセルホテルも、人気のある斜蚭はすぐに満宀になるこずがありたす。こちらも早めの予玄を。 * ** 京郜埡所の予玄 : ** 事前予玄が必芁ですので、忘れずに手続きしおください。 * ** 芳光斜蚭の開通時間 : ** 各斜蚭の開通時間を事前に確認し、効率よく芳光できるように蚈画を立おたしょう。 * ** 移動時間 : ** 垂バスや電車での移動時間を考慮し、無理のないスケゞュヌルを立おたしょう。 * ** 持ち物 : ** 歩きやすい靎、防寒具、雚具などを忘れずに準備したしょう。 このプランで、京郜の魅力を存分に楜しんでください 良い旅になりたすように cost_agent : ありがずうございたす 完璧なプランニングですね。補足事項も非垞に的確で、旅行者が安心しお旅を楜しめるよう、现やかな配慮がされおいたす。 このプランを参考に、楜しい京郜旅行を満喫しおください 䜕か他に質問があれば、お気軜にお尋ねください。 review_agent : ありがずうございたす こちらこそ、玠晎らしいプランを䞀緒に䜜り䞊げるこずができ、倧倉光栄です。䜕かお圹に立おるこずがあれば、い぀でもお声がけください。 良い旅になりたすように 単䞀゚ヌゞェントChatGPTのようなの䜿甚ずマルチ゚ヌゞェントの䜿甚の比范 同じ質問に察するChatGPTの出力 【1日目枅氎寺ず祇園】 枅氎寺400円を参拝。䞉幎坂・二幎坂を散策。昌食はカフェで玄1,200円。午埌は祇園を歩く。倕食はうどん玄900円。 合蚈玄3,000円 【2日目嵐山゚リア】 JRで嵐山ぞ240円。竹林の小埄無料、倩韍寺庭園500円。川蟺でお匁圓900円。垌望があれば猿山600円。倕食は1,000円ほど。 合蚈玄3,500円 【3日目䌏芋皲荷ず錊垂堎】 䌏芋皲荷無料。朝食600円。錊垂堎ぞ210円。食べ歩き1,200円。河原町を散策。倕食1,200円。 合蚈玄3,200円 【総費甚玄1〜1.5䞇円宿泊陀く】 䜙裕で5䞇円以内に収たりたす。 安いバヌゞョン、豪華バヌゞョン、が必芁であればお知らせください。 特城 単䞀゚ヌゞェント(ChatGPT) マルチ゚ヌゞェント タスク 䞀぀のモデルがすべおをこなす 専門家ごずに異なる業務を担圓する ゚ラヌチェック なし レビュヌ担圓者が誀りを発芋する 反埩 ナヌザヌは改善を芁求しなければならない ゚ヌゞェントは自動的に互いを掗緎させる 出力品質 良いが、単調である 構造化された、階局化された、より深い出力 結論 オヌトゞェンはAIの掻甚方法におけるパラダむムシフトです。協調知胜を実珟するこずで、単䞀゚ヌゞェントシステムでは達成できない可胜性を解き攟ちたす。開発者、研究者、技術愛奜家の方々に、オヌトゞェンは力になりたす。 オヌトゲンの真䟡は、モデルが賢くなるこずではなく、ワヌクフロヌが効率化されるこずにある。 むベント告知 12月23日にむベントを開催したす申し蟌みはこちらから▌ https://mynaviit.connpass.com/event/376769
本蚘事は【 Advent Calendar 2025 】の12日目の蚘事です。 結論 フロント゚ンドでは、OrvalでzodではなくFetch Clientを生成するこずを怜蚎しおみおはいかがでしょうか Orvalずは Orval ずは、OpenAPIからTypeScriptのコヌドを生成できるツヌルです。 䟋えば、以䞋のようなコヌドが生成できたす。 Fetch Client React Query Zod Hono このように、Orvalは様々な皮類のコヌドを生成できるずおも䟿利なツヌルです。 しかし、䜿い方によっおは、逆に保守性の䜎䞋を匕き起こす可胜性がありたす。 特に、「フロント゚ンドでzodを生成させおいる」こずが課題ずなるケヌスがありたす。 そこで、本蚘事ではフロント゚ンドでOrvalにzodを生成させるこずに぀いお、いく぀かの芳点から考察しおいきたす。 Fetch Clientずいう遞択肢 フロント゚ンドにおいお、なぜOrvalを䜿甚するのでしょうか それは、APIのレスポンスに型が欲しいからです。 zodを生成させるこずで型を埗るこずができたすが、Fetch Clientを生成させるこずでも同様に実珟でき、より簡朔にできる可胜性がありたす。 zodずFetch Clientの比范 では、zodを生成させた堎合ずFetch Clientを生成させた堎合のコヌドを比范しおみたしょう。 OpenAPI openapi: 3.0.0servers: - url: 'http://petstore.swagger.io/v2'info: description: >- This is a sample server Petstore server. For this sample, you can use the api key `special-key` to test the authorization filters. version: 1.0.0 title: OpenAPI Petstore license: name: Apache-2.0 url: 'https://www.apache.org/licenses/LICENSE-2.0.html'tags: - name: pet description: Everything about your Pets - name: store description: Access to Petstore orders - name: user description: Operations about userpaths: /pet: post: tags: - pet summary: Add a new pet to the store description: '' operationId: addPet responses: '200': description: successful operation content: application/xml: schema: $ref: '#/components/schemas/Pet' application/json: schema: $ref: '#/components/schemas/Pet' '405': description: Invalid input security: - petstore_auth: - 'write:pets' - 'read:pets' requestBody: $ref: '#/components/requestBodies/Pet' put: tags: - pet summary: Update an existing pet description: '' operationId: updatePet externalDocs: url: "http://petstore.swagger.io/v2/doc/updatePet" description: "API documentation for the updatePet operation" responses: '200': description: successful operation content: application/xml: schema: $ref: '#/components/schemas/Pet' application/json: schema: $ref: '#/components/schemas/Pet' '400': description: Invalid ID supplied '404': description: Pet not found '405': description: Validation exception security: - petstore_auth: - 'write:pets' - 'read:pets' requestBody: $ref: '#/components/requestBodies/Pet' /pet/findByStatus: get: tags: - pet summary: Finds Pets by status description: Multiple status values can be provided with comma separated strings operationId: findPetsByStatus parameters: - name: status in: query description: Status values that need to be considered for filter required: true style: form explode: false deprecated: true schema: type: array items: type: string enum: - available - pending - sold default: available responses: '200': description: successful operation content: application/xml: schema: type: array items: $ref: '#/components/schemas/Pet' application/json: schema: type: array items: $ref: '#/components/schemas/Pet' '400': description: Invalid status value security: - petstore_auth: - 'read:pets' /pet/findByTags: get: tags: - pet summary: Finds Pets by tags description: >- Multiple tags can be provided with comma separated strings. Use tag1, tag2, tag3 for testing. operationId: findPetsByTags parameters: - name: tags in: query description: Tags to filter by required: true style: form explode: false schema: type: array items: type: string responses: '200': description: successful operation content: application/xml: schema: type: array items: $ref: '#/components/schemas/Pet' application/json: schema: type: array items: $ref: '#/components/schemas/Pet' '400': description: Invalid tag value security: - petstore_auth: - 'read:pets' deprecated: true '/pet/{petId}': get: tags: - pet summary: Find pet by ID description: Returns a single pet operationId: getPetById parameters: - name: petId in: path description: ID of pet to return required: true schema: type: integer format: int64 responses: '200': description: successful operation content: application/xml: schema: $ref: '#/components/schemas/Pet' application/json: schema: $ref: '#/components/schemas/Pet' '400': description: Invalid ID supplied '404': description: Pet not found security: - api_key: [] post: tags: - pet summary: Updates a pet in the store with form data description: '' operationId: updatePetWithForm parameters: - name: petId in: path description: ID of pet that needs to be updated required: true schema: type: integer format: int64 responses: '405': description: Invalid input security: - petstore_auth: - 'write:pets' - 'read:pets' requestBody: content: application/x-www-form-urlencoded: schema: type: object properties: name: description: Updated name of the pet type: string status: description: Updated status of the pet type: string delete: tags: - pet summary: Deletes a pet description: '' operationId: deletePet parameters: - name: api_key in: header required: false schema: type: string - name: petId in: path description: Pet id to delete required: true schema: type: integer format: int64 responses: '400': description: Invalid pet value security: - petstore_auth: - 'write:pets' - 'read:pets' '/pet/{petId}/uploadImage': post: tags: - pet summary: uploads an image description: '' operationId: uploadFile parameters: - name: petId in: path description: ID of pet to update required: true schema: type: integer format: int64 responses: '200': description: successful operation content: application/json: schema: $ref: '#/components/schemas/ApiResponse' security: - petstore_auth: - 'write:pets' - 'read:pets' requestBody: content: multipart/form-data: schema: type: object properties: additionalMetadata: description: Additional data to pass to server type: string file: description: file to upload type: string format: binary /store/inventory: get: tags: - store summary: Returns pet inventories by status description: Returns a map of status codes to quantities operationId: getInventory responses: '200': description: successful operation content: application/json: schema: type: object additionalProperties: type: integer format: int32 security: - api_key: [] /store/order: post: tags: - store summary: Place an order for a pet description: '' operationId: placeOrder responses: '200': description: successful operation content: application/xml: schema: $ref: '#/components/schemas/Order' application/json: schema: $ref: '#/components/schemas/Order' '400': description: Invalid Order requestBody: content: application/json: schema: $ref: '#/components/schemas/Order' description: order placed for purchasing the pet required: true '/store/order/{orderId}': get: tags: - store summary: Find purchase order by ID description: >- For valid response try integer IDs with value <= 5 or > 10. Other values will generate exceptions operationId: getOrderById parameters: - name: orderId in: path description: ID of pet that needs to be fetched required: true schema: type: integer format: int64 minimum: 1 maximum: 5 responses: '200': description: successful operation content: application/xml: schema: $ref: '#/components/schemas/Order' application/json: schema: $ref: '#/components/schemas/Order' '400': description: Invalid ID supplied '404': description: Order not found delete: tags: - store summary: Delete purchase order by ID description: >- For valid response try integer IDs with value < 1000. Anything above 1000 or nonintegers will generate API errors operationId: deleteOrder parameters: - name: orderId in: path description: ID of the order that needs to be deleted required: true schema: type: string responses: '400': description: Invalid ID supplied '404': description: Order not found /user: post: tags: - user summary: Create user description: This can only be done by the logged in user. operationId: createUser responses: default: description: successful operation security: - api_key: [] requestBody: content: application/json: schema: $ref: '#/components/schemas/User' description: Created user object required: true /user/createWithArray: post: tags: - user summary: Creates list of users with given input array description: '' operationId: createUsersWithArrayInput responses: default: description: successful operation security: - api_key: [] requestBody: $ref: '#/components/requestBodies/UserArray' /user/createWithList: post: tags: - user summary: Creates list of users with given input array description: '' operationId: createUsersWithListInput responses: default: description: successful operation security: - api_key: [] requestBody: $ref: '#/components/requestBodies/UserArray' /user/login: get: tags: - user summary: Logs user into the system description: '' operationId: loginUser parameters: - name: username in: query description: The user name for login required: true schema: type: string pattern: '^[a-zA-Z0-9]+[a-zA-Z0-9\.\-_]*[a-zA-Z0-9]+$' - name: password in: query description: The password for login in clear text required: true schema: type: string responses: '200': description: successful operation headers: Set-Cookie: description: >- Cookie authentication key for use with the `api_key` apiKey authentication. schema: type: string example: AUTH_KEY=abcde12345; Path=/; HttpOnly X-Rate-Limit: description: calls per hour allowed by the user schema: type: integer format: int32 X-Expires-After: description: date in UTC when token expires schema: type: string format: date-time content: application/xml: schema: type: string application/json: schema: type: string '400': description: Invalid username/password supplied /user/logout: get: tags: - user summary: Logs out current logged in user session description: '' operationId: logoutUser responses: default: description: successful operation security: - api_key: [] '/user/{username}': get: tags: - user summary: Get user by user name description: '' operationId: getUserByName parameters: - name: username in: path description: The name that needs to be fetched. Use user1 for testing. required: true schema: type: string responses: '200': description: successful operation content: application/xml: schema: $ref: '#/components/schemas/User' application/json: schema: $ref: '#/components/schemas/User' '400': description: Invalid username supplied '404': description: User not found put: tags: - user summary: Updated user description: This can only be done by the logged in user. operationId: updateUser parameters: - name: username in: path description: name that need to be deleted required: true schema: type: string responses: '400': description: Invalid user supplied '404': description: User not found security: - api_key: [] requestBody: content: application/json: schema: $ref: '#/components/schemas/User' description: Updated user object required: true delete: tags: - user summary: Delete user description: This can only be done by the logged in user. operationId: deleteUser parameters: - name: username in: path description: The name that needs to be deleted required: true schema: type: string responses: '400': description: Invalid username supplied '404': description: User not found security: - api_key: []externalDocs: description: Find out more about Swagger url: 'http://swagger.io'components: requestBodies: UserArray: content: application/json: schema: type: array items: $ref: '#/components/schemas/User' description: List of user object required: true Pet: content: application/json: schema: $ref: '#/components/schemas/Pet' application/xml: schema: $ref: '#/components/schemas/Pet' description: Pet object that needs to be added to the store required: true securitySchemes: petstore_auth: type: oauth2 flows: implicit: authorizationUrl: 'http://petstore.swagger.io/api/oauth/dialog' scopes: 'write:pets': modify pets in your account 'read:pets': read your pets api_key: type: apiKey name: api_key in: header schemas: Order: title: Pet Order description: An order for a pets from the pet store type: object properties: id: type: integer format: int64 petId: type: integer format: int64 quantity: type: integer format: int32 shipDate: type: string format: date-time status: type: string description: Order Status enum: - placed - approved - delivered complete: type: boolean default: false xml: name: Order Category: title: Pet category description: A category for a pet type: object properties: id: type: integer format: int64 name: type: string pattern: '^[a-zA-Z0-9]+[a-zA-Z0-9\.\-_]*[a-zA-Z0-9]+$' xml: name: Category User: title: a User description: A User who is purchasing from the pet store type: object properties: id: type: integer format: int64 username: type: string firstName: type: string lastName: type: string email: type: string password: type: string phone: type: string userStatus: type: integer format: int32 description: User Status xml: name: User Tag: title: Pet Tag description: A tag for a pet type: object properties: id: type: integer format: int64 name: type: string xml: name: Tag Pet: title: a Pet description: A pet for sale in the pet store type: object required: - name - photoUrls properties: id: type: integer format: int64 category: $ref: '#/components/schemas/Category' name: type: string example: doggie photoUrls: type: array xml: name: photoUrl wrapped: true items: type: string tags: type: array xml: name: tag wrapped: true items: $ref: '#/components/schemas/Tag' status: type: string description: pet status in the store deprecated: true enum: - available - pending - sold xml: name: Pet ApiResponse: title: An uploaded response description: Describes the result of uploading an image resource type: object properties: code: type: integer format: int32 type: type: string message: type: string openapi : 3.0.0 servers : - url : ' http://petstore.swagger.io/v2 ' info : description : >- This is a sample server Petstore server. For this sample, you can use the api key `special-key` to test the authorization filters. version : 1.0.0 title : OpenAPI Petstore license : name : Apache-2.0 url : ' https://www.apache.org/licenses/LICENSE-2.0.html ' tags : - name : pet description : Everything about your Pets - name : store description : Access to Petstore orders - name : user description : Operations about user paths : /pet : post : tags : - pet summary : Add a new pet to the store description : '' operationId : addPet responses : ' 200 ' : description : successful operation content : application/xml : schema : $ref : ' #/components/schemas/Pet ' application/json : schema : $ref : ' #/components/schemas/Pet ' ' 405 ' : description : Invalid input security : - petstore_auth : - ' write:pets ' - ' read:pets ' requestBody : $ref : ' #/components/requestBodies/Pet ' put : tags : - pet summary : Update an existing pet description : '' operationId : updatePet externalDocs : url : " http://petstore.swagger.io/v2/doc/updatePet " description : " API documentation for the updatePet operation " responses : ' 200 ' : description : successful operation content : application/xml : schema : $ref : ' #/components/schemas/Pet ' application/json : schema : $ref : ' #/components/schemas/Pet ' ' 400 ' : description : Invalid ID supplied ' 404 ' : description : Pet not found ' 405 ' : description : Validation exception security : - petstore_auth : - ' write:pets ' - ' read:pets ' requestBody : $ref : ' #/components/requestBodies/Pet ' /pet/findByStatus : get : tags : - pet summary : Finds Pets by status description : Multiple status values can be provided with comma separated strings operationId : findPetsByStatus parameters : - name : status in : query description : Status values that need to be considered for filter required : true style : form explode : false deprecated : true schema : type : array items : type : string enum : - available - pending - sold default : available responses : ' 200 ' : description : successful operation content : application/xml : schema : type : array items : $ref : ' #/components/schemas/Pet ' application/json : schema : type : array items : $ref : ' #/components/schemas/Pet ' ' 400 ' : description : Invalid status value security : - petstore_auth : - ' read:pets ' /pet/findByTags : get : tags : - pet summary : Finds Pets by tags description : >- Multiple tags can be provided with comma separated strings. Use tag1, tag2, tag3 for testing. operationId : findPetsByTags parameters : - name : tags in : query description : Tags to filter by required : true style : form explode : false schema : type : array items : type : string responses : ' 200 ' : description : successful operation content : application/xml : schema : type : array items : $ref : ' #/components/schemas/Pet ' application/json : schema : type : array items : $ref : ' #/components/schemas/Pet ' ' 400 ' : description : Invalid tag value security : - petstore_auth : - ' read:pets ' deprecated : true ' /pet/{petId} ' : get : tags : - pet summary : Find pet by ID description : Returns a single pet operationId : getPetById parameters : - name : petId in : path description : ID of pet to return required : true schema : type : integer format : int64 responses : ' 200 ' : description : successful operation content : application/xml : schema : $ref : ' #/components/schemas/Pet ' application/json : schema : $ref : ' #/components/schemas/Pet ' ' 400 ' : description : Invalid ID supplied ' 404 ' : description : Pet not found security : - api_key : [] post : tags : - pet summary : Updates a pet in the store with form data description : '' operationId : updatePetWithForm parameters : - name : petId in : path description : ID of pet that needs to be updated required : true schema : type : integer format : int64 responses : ' 405 ' : description : Invalid input security : - petstore_auth : - ' write:pets ' - ' read:pets ' requestBody : content : application/x-www-form-urlencoded : schema : type : object properties : name : description : Updated name of the pet type : string status : description : Updated status of the pet type : string delete : tags : - pet summary : Deletes a pet description : '' operationId : deletePet parameters : - name : api_key in : header required : false schema : type : string - name : petId in : path description : Pet id to delete required : true schema : type : integer format : int64 responses : ' 400 ' : description : Invalid pet value security : - petstore_auth : - ' write:pets ' - ' read:pets ' ' /pet/{petId}/uploadImage ' : post : tags : - pet summary : uploads an image description : '' operationId : uploadFile parameters : - name : petId in : path description : ID of pet to update required : true schema : type : integer format : int64 responses : ' 200 ' : description : successful operation content : application/json : schema : $ref : ' #/components/schemas/ApiResponse ' security : - petstore_auth : - ' write:pets ' - ' read:pets ' requestBody : content : multipart/form-data : schema : type : object properties : additionalMetadata : description : Additional data to pass to server type : string file : description : file to upload type : string format : binary /store/inventory : get : tags : - store summary : Returns pet inventories by status description : Returns a map of status codes to quantities operationId : getInventory responses : ' 200 ' : description : successful operation content : application/json : schema : type : object additionalProperties : type : integer format : int32 security : - api_key : [] /store/order : post : tags : - store summary : Place an order for a pet description : '' operationId : placeOrder responses : ' 200 ' : description : successful operation content : application/xml : schema : $ref : ' #/components/schemas/Order ' application/json : schema : $ref : ' #/components/schemas/Order ' ' 400 ' : description : Invalid Order requestBody : content : application/json : schema : $ref : ' #/components/schemas/Order ' description : order placed for purchasing the pet required : true ' /store/order/{orderId} ' : get : tags : - store summary : Find purchase order by ID description : >- For valid response try integer IDs with value <= 5 or > 10. Other values will generate exceptions operationId : getOrderById parameters : - name : orderId in : path description : ID of pet that needs to be fetched required : true schema : type : integer format : int64 minimum : 1 maximum : 5 responses : ' 200 ' : description : successful operation content : application/xml : schema : $ref : ' #/components/schemas/Order ' application/json : schema : $ref : ' #/components/schemas/Order ' ' 400 ' : description : Invalid ID supplied ' 404 ' : description : Order not found delete : tags : - store summary : Delete purchase order by ID description : >- For valid response try integer IDs with value < 1000. Anything above 1000 or nonintegers will generate API errors operationId : deleteOrder parameters : - name : orderId in : path description : ID of the order that needs to be deleted required : true schema : type : string responses : ' 400 ' : description : Invalid ID supplied ' 404 ' : description : Order not found /user : post : tags : - user summary : Create user description : This can only be done by the logged in user. operationId : createUser responses : default : description : successful operation security : - api_key : [] requestBody : content : application/json : schema : $ref : ' #/components/schemas/User ' description : Created user object required : true /user/createWithArray : post : tags : - user summary : Creates list of users with given input array description : '' operationId : createUsersWithArrayInput responses : default : description : successful operation security : - api_key : [] requestBody : $ref : ' #/components/requestBodies/UserArray ' /user/createWithList : post : tags : - user summary : Creates list of users with given input array description : '' operationId : createUsersWithListInput responses : default : description : successful operation security : - api_key : [] requestBody : $ref : ' #/components/requestBodies/UserArray ' /user/login : get : tags : - user summary : Logs user into the system description : '' operationId : loginUser parameters : - name : username in : query description : The user name for login required : true schema : type : string pattern : ' ^[a-zA-Z0-9]+[a-zA-Z0-9\.\-_]*[a-zA-Z0-9]+$ ' - name : password in : query description : The password for login in clear text required : true schema : type : string responses : ' 200 ' : description : successful operation headers : Set-Cookie : description : >- Cookie authentication key for use with the `api_key` apiKey authentication. schema : type : string example : AUTH_KEY=abcde12345; Path=/; HttpOnly X-Rate-Limit : description : calls per hour allowed by the user schema : type : integer format : int32 X-Expires-After : description : date in UTC when token expires schema : type : string format : date-time content : application/xml : schema : type : string application/json : schema : type : string ' 400 ' : description : Invalid username/password supplied /user/logout : get : tags : - user summary : Logs out current logged in user session description : '' operationId : logoutUser responses : default : description : successful operation security : - api_key : [] ' /user/{username} ' : get : tags : - user summary : Get user by user name description : '' operationId : getUserByName parameters : - name : username in : path description : The name that needs to be fetched. Use user1 for testing. required : true schema : type : string responses : ' 200 ' : description : successful operation content : application/xml : schema : $ref : ' #/components/schemas/User ' application/json : schema : $ref : ' #/components/schemas/User ' ' 400 ' : description : Invalid username supplied ' 404 ' : description : User not found put : tags : - user summary : Updated user description : This can only be done by the logged in user. operationId : updateUser parameters : - name : username in : path description : name that need to be deleted required : true schema : type : string responses : ' 400 ' : description : Invalid user supplied ' 404 ' : description : User not found security : - api_key : [] requestBody : content : application/json : schema : $ref : ' #/components/schemas/User ' description : Updated user object required : true delete : tags : - user summary : Delete user description : This can only be done by the logged in user. operationId : deleteUser parameters : - name : username in : path description : The name that needs to be deleted required : true schema : type : string responses : ' 400 ' : description : Invalid username supplied ' 404 ' : description : User not found security : - api_key : [] externalDocs : description : Find out more about Swagger url : ' http://swagger.io ' components : requestBodies : UserArray : content : application/json : schema : type : array items : $ref : ' #/components/schemas/User ' description : List of user object required : true Pet : content : application/json : schema : $ref : ' #/components/schemas/Pet ' application/xml : schema : $ref : ' #/components/schemas/Pet ' description : Pet object that needs to be added to the store required : true securitySchemes : petstore_auth : type : oauth2 flows : implicit : authorizationUrl : ' http://petstore.swagger.io/api/oauth/dialog ' scopes : ' write:pets ' : modify pets in your account ' read:pets ' : read your pets api_key : type : apiKey name : api_key in : header schemas : Order : title : Pet Order description : An order for a pets from the pet store type : object properties : id : type : integer format : int64 petId : type : integer format : int64 quantity : type : integer format : int32 shipDate : type : string format : date-time status : type : string description : Order Status enum : - placed - approved - delivered complete : type : boolean default : false xml : name : Order Category : title : Pet category description : A category for a pet type : object properties : id : type : integer format : int64 name : type : string pattern : ' ^[a-zA-Z0-9]+[a-zA-Z0-9\.\-_]*[a-zA-Z0-9]+$ ' xml : name : Category User : title : a User description : A User who is purchasing from the pet store type : object properties : id : type : integer format : int64 username : type : string firstName : type : string lastName : type : string email : type : string password : type : string phone : type : string userStatus : type : integer format : int32 description : User Status xml : name : User Tag : title : Pet Tag description : A tag for a pet type : object properties : id : type : integer format : int64 name : type : string xml : name : Tag Pet : title : a Pet description : A pet for sale in the pet store type : object required : - name - photoUrls properties : id : type : integer format : int64 category : $ref : ' #/components/schemas/Category ' name : type : string example : doggie photoUrls : type : array xml : name : photoUrl wrapped : true items : type : string tags : type : array xml : name : tag wrapped : true items : $ref : ' #/components/schemas/Tag ' status : type : string description : pet status in the store deprecated : true enum : - available - pending - sold xml : name : Pet ApiResponse : title : An uploaded response description : Describes the result of uploading an image resource type : object properties : code : type : integer format : int32 type : type : string message : type : string orval.config.ts /** * @summary Add a new pet to the store */export const addPetBodyCategoryNameRegExp = new RegExp( '^[a-zA-Z0-9]+[a-zA-Z0-9\\.\\-_]*[a-zA-Z0-9]+$',);export const addPetBody = zod .object({ id: zod.number().optional(), category: zod .object({ id: zod.number().optional(), name: zod.string().regex(addPetBodyCategoryNameRegExp).optional(), }) .optional() .describe('A category for a pet'), name: zod.string(), photoUrls: zod.array(zod.string()), tags: zod .array( zod .object({ id: zod.number().optional(), name: zod.string().optional(), }) .describe('A tag for a pet'), ) .optional(), status: zod .enum(['available', 'pending', 'sold']) .optional() .describe('pet status in the store'), }) .describe('A pet for sale in the pet store');export const addPetResponseCategoryNameRegExp = new RegExp( '^[a-zA-Z0-9]+[a-zA-Z0-9\\.\\-_]*[a-zA-Z0-9]+$',);export const addPetResponse = zod .object({ id: zod.number().optional(), category: zod .object({ id: zod.number().optional(), name: zod.string().regex(addPetResponseCategoryNameRegExp).optional(), }) .optional() .describe('A category for a pet'), name: zod.string(), photoUrls: zod.array(zod.string()), tags: zod .array( zod .object({ id: zod.number().optional(), name: zod.string().optional(), }) .describe('A tag for a pet'), ) .optional(), status: zod .enum(['available', 'pending', 'sold']) .optional() .describe('pet status in the store'), }) .describe('A pet for sale in the pet store'); /** * @ summary Add a new pet to the store */ export const addPetBodyCategoryNameRegExp = new RegExp ( ' ^[a-zA-Z0-9]+[a-zA-Z0-9 \\ . \\ -_]*[a-zA-Z0-9]+$ ' , ) ; export const addPetBody = zod . object ( { id : zod . number () . optional () , category : zod . object ( { id : zod . number () . optional () , name : zod . string () . regex ( addPetBodyCategoryNameRegExp ) . optional () , } ) . optional () . describe ( ' A category for a pet ' ) , name : zod . string () , photoUrls : zod . array ( zod . string ()) , tags : zod . array ( zod . object ( { id : zod . number () . optional () , name : zod . string () . optional () , } ) . describe ( ' A tag for a pet ' ) , ) . optional () , status : zod . enum ([ ' available ' , ' pending ' , ' sold ' ]) . optional () . describe ( ' pet status in the store ' ) , } ) . describe ( ' A pet for sale in the pet store ' ) ; export const addPetResponseCategoryNameRegExp = new RegExp ( ' ^[a-zA-Z0-9]+[a-zA-Z0-9 \\ . \\ -_]*[a-zA-Z0-9]+$ ' , ) ; export const addPetResponse = zod . object ( { id : zod . number () . optional () , category : zod . object ( { id : zod . number () . optional () , name : zod . string () . regex ( addPetResponseCategoryNameRegExp ) . optional () , } ) . optional () . describe ( ' A category for a pet ' ) , name : zod . string () , photoUrls : zod . array ( zod . string ()) , tags : zod . array ( zod . object ( { id : zod . number () . optional () , name : zod . string () . optional () , } ) . describe ( ' A tag for a pet ' ) , ) . optional () , status : zod . enum ([ ' available ' , ' pending ' , ' sold ' ]) . optional () . describe ( ' pet status in the store ' ) , } ) . describe ( ' A pet for sale in the pet store ' ) ; zodの堎合: /** * @summary Add a new pet to the store */export const addPetBodyCategoryNameRegExp = new RegExp( '^[a-zA-Z0-9]+[a-zA-Z0-9\\.\\-_]*[a-zA-Z0-9]+$',);export const addPetBody = zod .object({ id: zod.number().optional(), category: zod .object({ id: zod.number().optional(), name: zod.string().regex(addPetBodyCategoryNameRegExp).optional(), }) .optional() .describe('A category for a pet'), name: zod.string(), photoUrls: zod.array(zod.string()), tags: zod .array( zod .object({ id: zod.number().optional(), name: zod.string().optional(), }) .describe('A tag for a pet'), ) .optional(), status: zod .enum(['available', 'pending', 'sold']) .optional() .describe('pet status in the store'), }) .describe('A pet for sale in the pet store');export const addPetResponseCategoryNameRegExp = new RegExp( '^[a-zA-Z0-9]+[a-zA-Z0-9\\.\\-_]*[a-zA-Z0-9]+$',);export const addPetResponse = zod .object({ id: zod.number().optional(), category: zod .object({ id: zod.number().optional(), name: zod.string().regex(addPetResponseCategoryNameRegExp).optional(), }) .optional() .describe('A category for a pet'), name: zod.string(), photoUrls: zod.array(zod.string()), tags: zod .array( zod .object({ id: zod.number().optional(), name: zod.string().optional(), }) .describe('A tag for a pet'), ) .optional(), status: zod .enum(['available', 'pending', 'sold']) .optional() .describe('pet status in the store'), }) .describe('A pet for sale in the pet store'); /** * @ summary Add a new pet to the store */ export const addPetBodyCategoryNameRegExp = new RegExp ( ' ^[a-zA-Z0-9]+[a-zA-Z0-9 \\ . \\ -_]*[a-zA-Z0-9]+$ ' , ) ; export const addPetBody = zod . object ( { id : zod . number () . optional () , category : zod . object ( { id : zod . number () . optional () , name : zod . string () . regex ( addPetBodyCategoryNameRegExp ) . optional () , } ) . optional () . describe ( ' A category for a pet ' ) , name : zod . string () , photoUrls : zod . array ( zod . string ()) , tags : zod . array ( zod . object ( { id : zod . number () . optional () , name : zod . string () . optional () , } ) . describe ( ' A tag for a pet ' ) , ) . optional () , status : zod . enum ([ ' available ' , ' pending ' , ' sold ' ]) . optional () . describe ( ' pet status in the store ' ) , } ) . describe ( ' A pet for sale in the pet store ' ) ; export const addPetResponseCategoryNameRegExp = new RegExp ( ' ^[a-zA-Z0-9]+[a-zA-Z0-9 \\ . \\ -_]*[a-zA-Z0-9]+$ ' , ) ; export const addPetResponse = zod . object ( { id : zod . number () . optional () , category : zod . object ( { id : zod . number () . optional () , name : zod . string () . regex ( addPetResponseCategoryNameRegExp ) . optional () , } ) . optional () . describe ( ' A category for a pet ' ) , name : zod . string () , photoUrls : zod . array ( zod . string ()) , tags : zod . array ( zod . object ( { id : zod . number () . optional () , name : zod . string () . optional () , } ) . describe ( ' A tag for a pet ' ) , ) . optional () , status : zod . enum ([ ' available ' , ' pending ' , ' sold ' ]) . optional () . describe ( ' pet status in the store ' ) , } ) . describe ( ' A pet for sale in the pet store ' ) ; Fetch Clientの堎合: /** * @summary Add a new pet to the store */export type addPetResponse200 = { data: Pet; status: 200;};export type addPetResponse405 = { data: null; status: 405;};export type addPetResponseComposite = addPetResponse200 | addPetResponse405;export type addPetResponse = addPetResponseComposite & { headers: Headers;};export const getAddPetUrl = () => { return `/pet`;};export const addPet = async ( petBody: PetBody, options?: RequestInit,): Promise<addPetResponse> => { const res = await fetch(getAddPetUrl(), { ...options, method: 'POST', headers: { 'Content-Type': 'application/json', ...options?.headers }, body: JSON.stringify(petBody), }); const body = [204, 205, 304].includes(res.status) ? null : await res.text(); const data: addPetResponse['data'] = body ? JSON.parse(body) : {}; return { data, status: res.status, headers: res.headers } as addPetResponse;}; /** * @ summary Add a new pet to the store */ export type addPetResponse200 = { data : Pet ; status : 200 ; } ; export type addPetResponse405 = { data : null ; status : 405 ; } ; export type addPetResponseComposite = addPetResponse200 | addPetResponse405 ; export type addPetResponse = addPetResponseComposite & { headers : Headers ; } ; export const getAddPetUrl = () => { return ` /pet ` ; } ; export const addPet = async ( petBody : PetBody , options ?: RequestInit , ) : Promise < addPetResponse > => { const res = await fetch ( getAddPetUrl () , { ... options , method : ' POST ' , headers : { ' Content-Type ' : ' application/json ' , ... options ?. headers }, body : JSON . stringify ( petBody ) , } ) ; const body = [ 204 , 205 , 304 ] . includes ( res . status ) ? null : await res . text () ; const data : addPetResponse [ ' data ' ] = body ? JSON . parse ( body ) : {} ; return { data , status : res . status , headers : res . headers } as addPetResponse ; } ; zodを生成させた堎合、生成されるのはあくたでもzodのスキヌマなので、実際にfetchする凊理は自分で曞く必芁がありたす。 それに察しお、Fetch Clientを生成させた堎合はfetchする凊理たで生成しおくれるので、ボむラヌプレヌトを枛らすこずができたす。 型安党性に぀いおの考察 Fetch Clientで生成させたコヌドを芋おもらうずわかりたすが、 as ​を䜿甚しお型のアサヌションを行っおいたす。 そうです。Fetch Clientで生成したコヌドは厳密には型安党ではありたせん。 しかし、ここで考えおみたいこずがありたす。 型安党ではないこずによっお、問題が発生するのはどのようなケヌスでしょうか それは、OpenAPIのスキヌマず実際にバック゚ンドから返っおくるスキヌマが異なるケヌスです。 そしお、それは果たしおフロント゚ンドの、しかもランタむム䞊で怜知すべきこずなのでしょうか それを螏たえるず、OpenAPIずバック゚ンドの霟霬がフロント゚ンドのランタむム䞊で刀明するのは理想的なタむミングずは蚀えないかもしれたせん。 したがっお、この問題はバック゚ンドの責務ず考え、バック゚ンド偎のテストで察凊する方が適切だず考えられたす。 バック゚ンドはフロント゚ンドを信頌しおはいけたせんが、フロント゚ンドはバック゚ンドを信頌するずいう考え方もできたす。 ランタむム怜蚌に぀いおの考え方 実際問題、ランタむム゚ラヌが発生したらどうするのか ずいう懞念もあるかず思いたす。 その堎合、玠盎に゚ラヌをthrowするずいう遞択肢がありたす。 OpenAPIずバック゚ンドに霟霬があるずいう臎呜的な問題が発生しおいる堎合、フロント゚ンド偎でできるこずは限られおいたす。 たた、Next.jsなら error.tsx ​を配眮しおおくこずで、゚ラヌ画面を衚瀺するこずができたす。 catchした埌どうするのか を念頭においお゚ラヌハンドリングを蚭蚈したしょう。 ク゚リパラメヌタやリク゚ストボディのバリデヌションに぀いお フロント゚ンドからバック゚ンドのAPIにリク゚ストを送る前に、ク゚リパラメヌタやリク゚ストボディのバリデヌションを行いたいずいうナヌスケヌスがあるず思いたす。 ここでは、䞀぀の考え方ずしお、その段階でのバリデヌションの必芁性に぀いお怜蚎しおみたす。 実際は、その盎埌にバック゚ンドがバリデヌションを行いたす。 したがっお、フロント゚ンド偎での重耇したバリデヌションは省略できる堎合が倚いです。 たた、フロント゚ンドで行うバリデヌションはUXのためであるずいう芖点を持぀こずが重芁です。 ぀たり、セキュリティや䞍正な倀を防ぐためのバリデヌションはバック゚ンドで行い、フロント゚ンドずバック゚ンドで二床同じバリデヌションを行う必芁性は䜎いず考えるこずができたす。 フォヌムのバリデヌションに぀いお UXのためのフォヌムのバリデヌションで、zodのスキヌマが欲しくなるケヌスがあるかもしれたせん。 その堎合は、フォヌムのスキヌマをAPIのスキヌマずは別に定矩するこずをおすすめしたす。 なぜなら、フォヌムのスキヌマはAPIのスキヌマず必ず察応しおいるずは限らないからです。 䟋えば、郵䟿番号を入力するずき、API偎では半角数字の文字列を期埅したすが、フォヌム偎ではUXのために党角数字の文字列も受け取れるようにしたい堎合がありたす。 たた、数倀入力でも、API偎では数倀型を期埅したすが、フォヌム偎では䞀時的に文字列ずしお扱い、カンマ区切りの衚瀺に察応したい堎合がありたす。 それ以倖でも、API偎は完成圢のオブゞェクトを期埅したすが、フォヌムでは段階的に異なる圢状のデヌタを扱うような堎合がありたす。 このような堎合、API偎のスキヌマは流甚できたせん。フロント゚ンド偎で独自に定矩する必芁がありたす。 こうなるず、APIのスキヌマを流甚するものず、しないものが混圚するこずになりたす。 そしお、珟状流甚できおいるスキヌマも、埌から倉曎される可胜性がありたす。 ぀たり、APIのスキヌマずフォヌムのスキヌマは本質的に異なるものであるず考えるこずができたす。 したがっお、フォヌムのスキヌマは仮にAPIのスキヌマず䞀臎しおいおも、別で定矩するこずを怜蚎しおみおはいかがでしょうか。 zodを生成した方が適しおいるケヌス ここたで、zodを生成しない遞択肢に぀いお考察しおきたしたが、zodを生成した方が適しおいるケヌスもありたす。 倖郚サヌビスのAPIを䜿甚する堎合 自分たちが管理しおいない倖郚APIを䜿甚する堎合は、zodによるランタむム怜蚌が有効な遞択肢ずなりたす。 なぜなら、OpenAPIスキヌマずバック゚ンドの実装に霟霬があっおも、バック゚ンド偎で修正するこずができないためです。 たた、倖郚APIは予告なく仕様が倉曎されるこずもありたす。 このような堎合、フロント゚ンド偎で防埡的にランタむム怜蚌し、䞍正なデヌタを早期に怜出するこずで、予期しない゚ラヌを防ぐこずができたす。 バック゚ンドでTypeScriptを䜿甚しおいる堎合 バック゚ンドでTypeScriptを䜿甚しおいる堎合、Orvalによるzod生成を掻甚するこずで、バック゚ンド偎でバリデヌションを行うこずができたす。 ただし、これはフロント゚ンドの話ではなく、バック゚ンドの話です。 (ここたで「フロント゚ンドにおける」ず匷調しおきたのはこのためです) バック゚ンドでは、フロント゚ンドから送られおくるリク゚ストボディやク゚リパラメヌタを信頌すべきではありたせん。 したがっお、バック゚ンド偎でランタむムバリデヌションを行う必芁がありたす。 このずき、OpenAPIからzodスキヌマを生成するこずで、バリデヌションのコヌドを自動生成でき、保守性を向䞊させるこずができたす。 補足: APIの型の䜿い方に぀いお zodの話ずは少し逞れたすが、Orvalを䜿う際に泚意したい点ずしお、APIの型をコンポヌネントからAPIクラむアントたで䜿い回すずいうアンチパタヌンがありたす。 前提ずしお、APIのレスポンスはJSONであり、それはシリアラむズされたDTOに過ぎたせん。 JSONはドメむン知識を持たず、ドメむンモデルずしお機胜しないため、Orvalが生成した型をフロント゚ンド偎であたかもドメむンモデルであるかのように盎接䟝存するず、様々な箇所で䞍敎合が発生する可胜性がありたす。 そのため、フロント゚ンドではフロント゚ンド甚のドメむンモデルを定矩するこずをおすすめしたす。 そしお、DTOをドメむンモデルに倉換するMapperを実装するこずも、䞀぀の有効なアプロヌチです。 この蟺りの話は以䞋の蚘事が参考になるため、よろしければ読んでみおください。 フロント゚ンド゚ンゞニアが「自分はJSON色付け係」ず自虐する理由を考察した フロント゚ンドにおける「型」の責任分解に察する1぀のアプロヌチ たずめ 本蚘事では、フロント゚ンドでOrvalを䜿甚する際に、zodではなくFetch Clientを生成するずいう遞択肢に぀いお考察したした。 重芁なポむントは以䞋の4぀です。 Fetch Clientを生成するこずで、zodよりも簡朔に型が぀いたAPI通信の凊理を曞ける ランタむム䞊でのOpenAPIずバック゚ンドの霟霬怜出は、バック゚ンドのテストで察凊する考え方もある フォヌムのスキヌマずAPIのスキヌマは本質的に異なる目的を持぀ APIのレスポンスはシリアラむズされたDTOであり、ドメむンモデルずは区別しお扱うこずが望たしい これらは䞀぀の考え方であり、プロゞェクトの状況やチヌムの方針によっお最適な遞択は異なりたす。 それぞれのアプロヌチのトレヌドオフを理解した䞊で、プロゞェクトに適した方法を遞択するこずをおすすめしたす。
本蚘事は【 Advent Calendar 2025 】の11日目の蚘事です。 はじめに こんにちはマむナビのN.Yです。 2025幎12/1(月)から12/5(金)に開催された「re:Invent2025」に参加したした。 自分にずっお初海倖出匵、初アメリカで䞍安もありたしたが、 結果的に倚くの孊びがあり、あっずいう間に過ぎた週間をご玹介したいず思いたす。 筆者に぀いお 新卒入瀟3幎目 瀟内のクラりド支揎郚眲所属 英語ずは倧孊受隓でお別れ、英語圏ぞの枡航経隓れロ re:Inventずは AWSが䞻催する䞖界最倧芏暡のクラりドカンファレンスで、毎幎12月に米囜ネバダ州ラスベガスで開催されたす。 今幎は14回目の開催ずなり、䞖界䞭から玄60,000人、日本からも1900人近くが参加したらしいです。 基調講挔Keynoteをはじめ、3000以䞊のセッション、パヌトナヌ䌁業の展瀺䌚EXPO、たくさんのむベント、ノベルティグッズなど、孊びから゚ンタメたで幅広く展開されたす。 䌚堎 「ラスベガス・ストリップ」ず呌ばれるカゞノ街にある耇数のホテルが䌚堎になりたす。 最も離れおいるホテルは歩いお1時間かかるほどの距離がありたす。 開催期間䞭、参加者は䌚堎間を぀なぐシャトルバスやモノレヌルが無料で利甚できるため、それらを駆䜿しお移動したす。 ホテル自䜓も巚倧なので、スケゞュヌルを組む際には移動時間も考慮する必芁がありたす。 今回、マむナビメンバヌが宿泊した Harrah's は、メむン䌚堎のVenetianぞも歩いお行ける距離にあり、アクセス良奜でずおも䟿利でした。 䞀週間の過ごし方 ここからは開催期間䞭の様子を、写真を亀えながらご玹介したす。 前段で述べたように、期間䞭さたざたなむベントやセッションが開催されおいたす。 あくたでも初めお参加した人間が䜓隓した䞀䟋ずしお眺めおいただければず思いたす。 ざっくりスケゞュヌル 11/30 矜田空枯出発 -- 日付倉曎線 -- 11/30 サンフランシスコ経由でラスベガス到着 12/1  12/4 re:Invent参加 12/5 ラスベガス出発、サンフランシスコ空枯経由 -- 日付倉曎線 -- 12/6 矜田空枯到着 2025/11/300日目 15:00 矜田空枯に集合 指定されおいた集合時間は15:00でしたが、心配性のマむナビメンバヌは13:00くらいには党員集合しおいたした。 今回はJTBツアヌで参加したため、案内に埓っお搭乗刞発行、荷物預け、保安怜査ぞず倧きなトラブルなく進むこずができたした。 18:00(JTC) 矜田空枯→サンフランシスコぞ出発 箄9時間の長距離フラむトです。機内食が2回提䟛されたした。 有料で機内Wi-Fiが利甚でき、過去のレポヌト蚘事を読んだり、セッションスケゞュヌルを組み盎したりした埌は、寝お過ごしたした。 ヌヌ日付倉曎線ヌヌ 19:00(PST) サンフランシスコ→ラスベガス到着 トランゞットのサンフランシスコで玄6時間埅機の埌、 1時間ほど飛行機の出発が遅れ、珟地時間の19時頃にラスベガスハヌリヌダヌド空枯に到着したした。 re:Invent参加者は、はじめに入堎バッゞを取埗する必芁があり、空枯や䌚堎で手続きができるのですが、この日は間に合わず翌日に取埗するこずにしたした。 ホテルに着いた埌は、荷物を眮いお早速ラスベガスの街を軜く散策したした。 翌日に備えお早めにホテルに戻っお就寝したした。 2025/12/0日目 8:00 ホテルベネチアンぞ移動 初めおのラスベガスの朝 先茩ず、すごい、でかい、すごい、ずか蚀いながら本䌚堎の Venetian ぞ移動したした。 入堎バッゞを取埗し、たずは朝食。 果おしなく広い䌚堎に円卓が広がっおおり、ビュッフェ圢匏で朝食が甚意されおいたした。 予玄しおいたセッションたで時間があったため、毎幎恒䟋ずなっおいるDatadog瀟提䟛の滑り台を滑ったり、巚倧黒板に瀟名を刻んだりしたした。 SWAG゚リアに行くず、re:Invent参加者特兞のパヌカヌずボトルをゲットできたした。 䌚堎の至る所に絊氎できるずころがあるので、もらったボトルは持ち歩いおおくず䟿利です。 パヌカヌは裏起毛で、ラスベガスの倜や なぜか冷房が効いおいる䌚堎では非垞に助けられたした。 10:00 Mandalay Bayぞ移動 Venetianから、最南の䌚堎であるMandalay Bayたでシャトルバスに乗っお20分ほどで到着したした。 午埌は、参加者が4名1チヌムに分かれお他チヌムず察戊する圢匏のセッションである「Game Day」に参加したり、いく぀かの実践型セッションを受講したした。 18:00 セッション終了 党おのセッションを終えお、開催前に日本での re:Invent参加者亀流䌚で知り合った方ず合流したした。 開催期間䞭は日本人が集たりがちず噂のお店「noodle asia」に行きたした。 私たち以倖に日本人はおらず、時間垯によるのかなず思い぀぀、 3000円くらいするワンタンメンを、味わいながらいただきたした。 2025/12/2日目 7:00 KeyNote この日は re:Invent メむンコンテンツの぀である AWS CEO Matt Garman氏の Keynote が午前䞭にあるため、早めにホテルを出おVenetian䌚堎ぞ向かいたす。 朝食を食べおから䌚堎ぞ向かったずころ、すでに本䌚堎は満員だったため䞭継䌚堎ぞ案内されたした。 本䌚堎に入るためには1時間前くらいから䞊んでおく必芁がありそうです、、 CEOのKeynoteでは、新しい機胜やサヌビスが次々に発衚されたした。 サヌビスアップデヌト玹介タむムアタックが始たったずきは、聎衆をワクワクさせる挔出に感動したした。 興味のある方はAWS の公匏Youtubeに公開されおいるので芋おみおください。 䌚堎ぞ向かう途䞭、バケットくんに遭遇 気さくな方で、䞀緒に写真を撮っおくれたした。 圓日に Keynote でGAが発衚された、S3 Vectors のゞャケット着甚バヌゞョンでアツいです。 バケットくんに぀いおもっず知りたい方はこちらも参照 【AWS re:Invent2024】S3バケットくん培底解剖 | マむナビ゚ンゞニアブログ Keynoteが終わった埌は Caesars Forum ぞ向かい、AWSに぀いお楜しみながら孊べるカヌドゲヌム「BuilderCards」をゲットしたした。 瀟内でメンバヌを募っお遊がうず思いたす。 11:00 セッション 午埌のセッションのため、Mandalay Bayぞ移動。 「DDos攻撃からAWS WAFを掻甚しおサヌビスを守り品質を保぀」ずいうシナリオのGameDayにマむナビ゚ンゞニア2名で参加したした。 セッション名AWS GameDay - Winning the DDos Game (SEC403-R) GameDayは、参加者が4人1チヌムに分かれお競うセッションです。 結果は17チヌム䞭4䜍でした。チヌムメむトの倖囜人が぀よ぀よだった 高めの蚀語の壁はありたしたが、WAFコン゜ヌル画面での操䜜や、攻撃的なアクセスを特定しお制埡する方法は勉匷になりたした。 終了埌、同じチヌムだったむスラ゚ル人にLinkedInのアカりントを持っおるか聞かれたした。 海倖の方ずの亀流は名刺亀換ではなく、LinkedInのアカりントを䜜成しおおくず良さそうです。 19:00 Japan Night 倜は今回ツアヌに参加させおいただいた JTBさん䞻催の日本人向け亀流むベントに参加したした。 普段、他瀟の゚ンゞニアず亀流する機䌚があたりないのですが、亀流䌚ならではの情報亀換ができお有意矩な時間ずなりたした。 ネットワヌキングも re:Invent の醍醐味であるこずを痛感したした。 2025/12/3日目 1日を通しおセッションに参加したした。 参加したセッション Accelerating Incident Resolution: AI-Driven Root Cause Analysis (COP320-R2) AIによる自動むンシデント調査機胜である CloudWatch Investigation を䜿甚しおアラヌト発生時のトラブルシュヌティング䜓隓 Building Serverless applications with Terraform workshop (CNS312-R) Terraformを䜿ったサヌバレスアヌキテクチャの構築䜓隓ワヌクショップ Amazon ECS observability patterns and design decisions (CNS351-R1) ECSのオブザヌバビリティやベストプラクティスな運甚方法に぀いおスピヌカヌず参加者がディスカッションするChalk talk。翻蚳機がないず、ちょっず䜕蚀っおるか分かんない状態でしたが、アメリカならではの熱いディスカッションを味わえたのは良い経隓でした。 Build Streaming Analytics Dashboards in Minutes with Kiro CLI (IND312-R1) Kiro CLIを䜿甚しお自然蚀語でのCDKアプリケヌションの構築を行うハンズオン。デプロむ埅ち時間が長く、スピヌカヌず参加者が生成AIのアンチテヌれに぀いお議論しおいるのを翻蚳機で聞いおいたした。 この日は他に特筆するこずがないので、 午埌になるず䌚堎に珟れるおや぀コヌナヌの写真を茉せたす。 おかげさたで日䞭垯は食事に困りたせんでした。 2025/12/4日目 8:00 朝食、EXPO 我々が参加するのはこの日が最埌でした。 い぀も通り朝食を枈たせた埌は、時間に䜙裕があったのでEXPOブヌスを巡りたした。 自分は参加できなかったのですが、ブヌスを呚りながらスタンプを集めるこずで豪華ノベルティがもらえる催しなどもあったみたいです。 AWSのデヌタセンタヌで管理されおいる物理サヌバヌが展瀺されおいたした。 業務で物理サヌバヌを芋る機䌚がないので新鮮でした。 12:00 セッション 午埌はハンズオン圢匏のセッションであるWorkShopず、AWS Japanが䞻催する日本人向けのセッション「Japan Wrap-up Session」を聎講したした。 日本語でre:Inventを振り返るこずができたす。 16:00 認定者ラりンゞ Venetian の2階にあるAWS認定資栌保持者のみが入堎できる認定者ラりンゞに寄っおみたした。 事前に認定資栌アカりントの登録をするこずで、最初からバッゞに印チェックマヌクが぀きたす。 自分は登録を忘れおいたので、受付で説明しお Credly の認定蚌画面を芋せるず快く印シヌルを貌っおくれたした。 䞭に入るず軜食や、いく぀かの怅子ずテヌブルが甚意されおいお、倚くの人がく぀ろぎながらKeynoteの䞭継を芳おいたした。 20:00 re:Play re:Inventを締めくくる、倧芏暡屋倖パヌティです。 PM19:00からAM0:00たで開かれおいお、東京ドヌムくらいの広さの䌚堎に飲食ブヌスや䜓隓型むベントブヌス、ラむブ䌚堎が䜵蚭されおいたした。 2025/12/5垰囜 珟地時間の AM3:30 頃にホテルのロビヌに集合し、ラスベガス空枯ぞ。 行きず同じくサンフランシスコ経由で垰りたす。 垰りの飛行機は11時間くらいのフラむトでした。 週間の疲劎ず緊匵がほどけ、着垭した瞬間からの蚘憶がありたせん。 日本時間の12月6日18:00頃、無事に矜田空枯に到着したした。 さようならラスベガス、ただいた日本。 最埌に 今回参加しおみお、䌚堎、むベント、AWSが創造する䞖界のスケヌルの倧きさに圧倒され぀぀、䞖界䞭から参加しおいる゚ンゞニアやAWS゚キスパヌトずの亀流を通しお、普段の業務では埗られない刺激を受けたした。 ゚ンゞニアはもちろん、非゚ンゞニアの方や勉匷䞭の方など、あらゆる立堎の方にずっお参加する䟡倀があるず思いたす。 ずは蚀え、費甚や枡航準備、䜓力などを考えるず気軜に参加できないのも事実です。 参加する機䌚を䞎えおくれた䌚瀟、そしお䞀緒に参加したメンバヌにはずおも感謝しおいたす 最埌たでお読みいただき、ありがずうございたした むベント告知 12月23日にむベントを開催したす申し蟌みはこちらから▌ https://mynaviit.connpass.com/event/376769
本蚘事は【 Advent Calendar 2025 】の10日目の蚘事です。 はじめに ITD2-2-1のH・Tです。マむナビで内補開発しおいたす。 開発珟堎で䜜業効率が萜ちるタスクがあったので、自分でラむブラリを䜜ったのでその玹介をしたす。 今埌の内補開発でも倧いに圹立぀かなず思っおたす。 なにを぀くったか Tatsumaki - Rails to TypeSpec Generator npmにすでに公開しおいたす。 https://www.npmjs.com/package/@tyranno269/tatsumaki ラむブラリが提䟛する䟡倀 RailsのDBスキヌマからTypeSpecモデルを自動生成するnpmラむブラリでスキヌマ駆動開発を簡易化できたす。 開発モチベヌション マむナビの開発珟堎では、Rails API + Next.js + zodによる型安党な開発が倚いです、ただ以䞋の課題がありたした。 手動倉換の煩雑さ: Rails schema.rb → TypeSpec → OpenAPI → zodの倉換チェヌンが手動 型同期の遅延: Rails偎の倉曎をフロント゚ンドに反映するのに時間がかかる 型䞍敎合のリスク: 手動倉換によるランタむム゚ラヌの発生 OpenAPIからZod生成では Orval ずいうラむブラリを䜿甚しおいたす。 これによっおOpenAPIからシヌムレスに実装を進められたす。䞀方でバック゚ンドのRailsからTypeSpecに曞き出すのは少々手間をかけおいたした。ここが自分は煩雑だなず感じおたした。これを解決しようず思ったのがラむブラリ開発のモチベヌションです。 Tatsumakiによる解決 # docsディレクトリで実行 npx @tyranno269/tatsumaki # → rails.tsp自動生成 → TypeSpec → OpenAPI → orval → zod型定矩 機胜 Rails schema.rbから自動でTypeSpec生成 Rails enum完党察応 - モデルファむルからenum定矩を自動抜出・生成 monorepo察応で柔軟なプロゞェクト構造をサポヌト 型安党性をRailsからフロント゚ンドたで䞀貫しお確保 Rails互換の単数圢化 ( company_branches ​ → CompanyBranch ​) 参考: activesupport/lib/active_support/inflections.rb 想定プロゞェクト構造 project/ ├── backend/     # Rails API │   ├── app/models/  # Rails enum定矩 │   └── db/ │       └── schema.rb ├── docs/        # TypeSpec (実行堎所) │   └── rails.tsp (生成される) └── frontend/    # Next.js + zod Rails Enum RailsにはModel局にEnum倀を定矩したす。曞き方が倚様にありたす。Schema.rbではintegerですが、APIレスポンスずしお返す倀はStringのケヌスが倚くあるので察応が必芁でした。ただしEnumもi18nで翻蚳ファむルを定矩するずバック゚ンドから日本語化しお返せたすが、フロント゚ンドメンバヌず盞談した結果、翻蚳はFE偎で察応するず良いずの結論になり、玔粋にmodelファむルの定矩をTypeSpecに出力したす。 察応するenum圢匏 class Company < ApplicationRecord # ハッシュ圢匏 enum :company_status, { disabled: 0, enabled: 1, suspended: 9 } # 配列圢匏 enum :status, [ :active, :archived ] # %i蚘法 enum :priority, %i(low medium high) # キヌワヌド匕数 enum priority: { low: 0, medium: 1, high: 2 } end class Book < ApplicationRecord   enum :status, [ :draft, :published, :archived ] end 生成されるTypeSpec namespace CompanyEnums {   enum CompanyStatus {     disabled,     enabled,     suspended,   }   enum Status {     active,     archived,   } } namespace BookEnums {   enum Status {     draft,     published,     archived,   } } model Company {   id: int64;   company_status: CompanyEnums.CompanyStatus; // default: "enabled"   status: CompanyEnums.Status; // default: "active"   created_at: utcDateTime;   updated_at: utcDateTime; } model Book {   id: int64;   name: string;   status: BookEnums.Status; // No naming conflict with CompanyEnums.Status   created_at: utcDateTime;   updated_at: utcDateTime; } enum機胜の特城 名前空間による衝突回避 - CompanyEnums.Status ​ vs BookEnums.Status ​ schema.rbずの連携 - テヌブル定矩があるモデルのみ凊理 型眮換 - int32 ​フィヌルドを適切な enum​ 型に倉換 å…šRails enum構文察応 - ハッシュ、配列、%i蚘法、キヌワヌド匕数 その他にも、 a_matsuda さんの Stateful_enum ずいったようにenum定矩からブロックでむベントを蚘述するずいったGemもありたす。TypeSpecの出力ではブロック郚分は回避する工倫もしたした。 開発フロヌ統合 Tatsumakiの蚭蚈により、Rails schema.rb + enum → TypeSpec → OpenAPI → zod の完党自動化チェヌンを実珟し、型安党なフルスタック開発を支揎可胜になりたした。 むンストヌル・䜿甚方法 # 実行最新版が自動取埗される npx @tyranno269/tatsumaki # 既存ファむル䞊曞き npx @tyranno269/tatsumaki --force # カスタム出力ファむル npx @tyranno269/tatsumaki --out models.tsp --force # 既存ファむルに远蚘 npx @tyranno269/tatsumaki --append マむナビでの今埌の掻甚方法 TypeSpecディレクトリ構成次第にはなりたすが様々なパタヌンの開発で応甚できうるかずおもいたす。 パタヌン1 project/ ├── backend/     # Rails API │   ├── app/models/  # Rails enum定矩 │   └── db/ │       └── schema.rb ├── docs/        # TypeSpec (実行堎所) │   └── rails.tsp (生成される) └── frontend/    # Next.js + zod 生成されるrails.tspにroutesになるオペレヌション情報を蚘述しおいくパタヌン パタヌン2 project/ ├── backend/     # Rails API │   ├── app/models/  # Rails enum定矩 │   └── db/ │       └── schema.rb ├── docs/        # TypeSpec (実行堎所) │   └── rails.tsp (生成される) │   └── routes │       └── admin │           └── admin.tsp (ex:管理サむトの管理者䞀芧・詳现など) │       └── user │           └── notice.tsp (ex:ナヌザヌサむトのお知らせ䞀芧・詳现など) └── frontend/    # Next.js + zod 生成されるrails.tspにroutesで定矩したオペレヌションをimportしお組み蟌んでいくパタヌン パタヌン3 project/ ├── backend/     # Rails API │   ├── app/models/  # Rails enum定矩 │   └── db/ │       └── schema.rb ├── docs/        # TypeSpec (実行堎所) │   └── rails.tsp (生成される) │   └── main.tsp (出力の芪ずなるファむル) │   └── models │       └── admin.tsp (rail.tspからnamespaceの該圓郚分をコピペで定矩) │       └── notice.tsp (rail.tspからnamespaceの該圓郚分をコピペで定矩) │   └── routes │       └── admin │           └── admin.tsp (ex:管理サむトの管理者䞀芧・詳现など) │       └── user │           └── notice.tsp (ex:ナヌザヌサむトのお知らせ䞀芧・詳现など) └── frontend/    # Next.js + zod 生成されるrails.tspからコピペで抜出し利甚しおいくパタヌン 最埌に 実際のRailsのプロゞェクトで䜿甚される䞻芁機胜をカバヌできたかなず思っおいたす。よかったら利甚しおみおください。今回は自分の䜜業時間を枛らしたいモチベヌションで生み出したラむブラリなので実際のナヌスケヌスで察応できおいないこずもあるかなず思いたす。芁望があれば Github Issue に䞊げお頂けたすず嬉しいです むベント告知 12月23日にむベントを開催したす申し蟌みはこちらから▌ https://mynaviit.connpass.com/event/376769
本蚘事は【 Advent Calendar 】の9日目の蚘事です。 AI戊略宀のM・Wです。この蚘事を曞いおいるのは12月1日です。 11月30日にゞャパンカップで カランダガン の単勝ず䞉連単を取りたした。珟地で芳戊をしおいたのですが、倧倉興奮したレヌスでした。ゎヌル間際の2頭の叩き合いに混ざる空銬。 ぜひYoutubeで動画を芋おください。以䞊、12月11日の蚘事でした 沌の淵 突然ですが、forkやspawnの違いに぀いお知っおいたすでしょうか。 私は知らなかったです。いたも正盎わかりたせん。 その結果、沌にハマっおしたいたした。抜け出せないたた今日を過ごしおいたす。 これは自分甚のメモ+同じようなこずを実装する人がいた際の䞀助になればいいなず思っお執筆しおいたす。 たずずあるAgentを考えたす。このAgentは「環境」を知芚し「行動」を決定するAgentです。 Agentは「行動」を行うず「環境」から「報酬」を手にするこずができ、「環境」は次の「状態」に遷移したす。 図にするずこんな感じです。これは基本的な匷化孊習を説明する際に甚いられる簡略図です。 今回、ボン◯ヌマンのようなPvPをするゲヌムに぀いお、匷化孊習を䜿っお゚ヌゞェントを䜜る機䌚がありたした。぀たり䞊の画像に照らし合わせるず䞋蚘の衚ずなりたす。 甚語 察応 環境 ゲヌム自䜓 ゚ヌゞェント 操䜜キャラクタヌ 状態 その時時の盀面 行動 移動+ボム配眮+キック 報酬 勝利/敗北など レギュレヌションずしお自陣営は2぀のBotを甚意する2vs2の察決ず提瀺されたため、䞊蚘の゚ヌゞェントが2぀必芁なマルチ゚ヌゞェント孊習を行う必芁がありたした。 ちなみに特に実装は指定されなかったのでロゞックで蚘述するでもOKです。AI郚眲なので匷化孊習で挑みたした 沌にダむブ ここでいよいよ掲題に出おきたマルチプロセス孊習の話ができおたす。 最新の匷化孊習アルゎリズムに疎かったので、䞀旊Actor-CriticベヌスのA3Cアルゎリズムを遞択したした。実装したモデル構造は䞋蚘ずなりたす。 盀面の゚ンコヌドやモデル蚭蚈に぀いおは以䞋のモデルを参考ずしおいたす。Cursor先生ありがずう Multi-Agent Training for Pommerman: Curriculum Learning and Population-based Self-Play Approach: https://arxiv.org/abs/2407.00662 マルチプロセス孊習の党䜓感ずしおは䞋蚘の図です。 ゲヌム盀面を提䟛するホスト偎ず゚ヌゞェント間はWebSocketによる疎通を行う必芁があるため、各BotごずにWebSocketサヌバを子プロセスずしお䜜成したす。 ぀たり子プロセス䞊では、ゲヌム開始から終了たで実行されたすが、そこで収集したデヌタに぀いおは䜕かしらの方法を䜿っお芪プロセス䞊に移動させないず、子プロセスがterminateされた際に砎棄されおしたう問題がありたす。 そのため 共有メモリ を䜿っお誀差募配を芪プロセス偎ず共有を行い、最適化噚を䜿っお共有モデルのパラメヌタを曎新、次の孊習ルヌプで子プロセスぞ配分を繰り返し孊習を行っおいきたす。 沌の底 孊習モデルを共有メモリに配眮するためには model.share_memory() を実斜したすが、今回の実装のケヌスにおいおたびたび子プロセスの model.backward() が倱敗する事象がありたした。 いく぀か問題はありたしたが、 ・䞋蚘のログが出力され、backward凊理が倱敗するケヌス objc[8623]: +[MPSGraphObject initialize] may have been in progress in another thread when fork() was called.objc[8623]: +[MPSGraphObject initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug. ・backward()が呌び出された際に子プロセスがクラッシュしお音もなく消える 䜿甚しおる端末がMacOSであるため、前者のケヌスでは $export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES を実行するこずで゚ラヌ文が出力されなくなりたす。しかしながらこれはワヌクアラりンドずなりたす。 MacOSでは fork() が実行された際に、芪プロセスで既に初期化され぀぀あったObjective-Cのデヌタ構造が子プロセスに匕き継がれるず、子プロセス偎でその初期化が安党に完了できない状況が発生するこずがありたす。これにより、子プロセスがクラッシュ通垞はEXC_BAD_ACCESSしたり、デッドロックしたりしたす。 Pythonのmultiprocessingは、デフォルトでは「fork」方匏を䜿っお新しいプロセスを生成するため、この問題に盎面しやすいです。そのため2点目の音もなく子プロセスが消えた原因も含めお、backward()凊理がうたく動䜜しないのは fork() による子プロセスの生成に問題があるず結論付けたした。 ちなみにPyTorchからマルチプロセス孊習する際のベストプラクティスでも「Use an alternative process start methods, such as spawn or forkserver, which ensures a clean initialization of each process.」ず蚘茉がありたす。 https://docs.pytorch.org/docs/stable/notes/multiprocessing.html#poison-fork-in-multiprocessing spawn は fork ずは違い、Pythonむンタヌプリタごずプロセスを生成したす。起動が遅いずいうデメリットはありたすが、必芁な情報のみを芪プロセスから匕き継ぐ点や䞊蚘の初期化に起因するような゚ラヌを回避できるメリットがありたす。 実隓 簡単なNNを構築しおspawnを䜿甚したbackward()がうたくいくかどうかを実隓しおみたす。 import torchimport torch.nn as nnimport torch.multiprocessing as mpimport torch.nn.functional as Fimport torch.optim as optimclass ExampleNN(nn.Module): def __init__(self): super(ExampleNN, self).__init__() self.fc = nn.Linear(10, 1) def forward(self, x): out = self.fc(x) return F.sigmoid(out)def train(xs, target): model = ExampleNN() optimizer = optim.SGD(model.parameters()) out = model(xs) loss = F.binary_cross_entropy(out, target) optimizer.zero_grad() loss.backward() optimizer.step() print('trainメ゜ッドが終了したよ') 䞊蚘のtrainメ゜ッドをforkで動かしおみたす。 if __name__ == '__main__': x = torch.rand(1, 5, 10) t = torch.Tensor([0, 1, 1, 0, 1]).reshape(1, 5, 1) train(x, t) print('-'*54) ctx = mp.get_context('fork') processes = [] for i in range(5): p = ctx.Process(target=train, args=(x, t)) p.start() processes.append(p) for p in processes: p.join()>>> trainメ゜ッドが終了したよ------------------------------------------------------RuntimeError: Unable to handle autograd's threading in combination with fork-based multiprocessing. See https://github.com/pytorch/pytorch/wiki/Autograd-and-Fork 無事゚ラヌが出たした。 ちなみに途䞭の train(x, t) をコメントアりトするず正垞に動䜜したす。これは䞊蚘のGithubにも蚘茉の通り、backward()で呌び出されおいるAutogradがすでに䜿甚されおいる状態でfork()されたこずに起因する゚ラヌずなりたす。 Autograd engine relies on threads pool, which makes it vulnerable to fork. We detect such situations and warn users to use spawn method of multiprocessing. 指瀺通りspawnでやっおみたしょう。 if __name__ == '__main__': x = torch.rand(1, 5, 10) t = torch.Tensor([0, 1, 1, 0, 1]).reshape(1, 5, 1) train(x, t) print('-'*54) ctx = mp.get_context('spawn') processes = [] for i in range(5): p = ctx.Process(target=train, args=(x, t)) p.start() processes.append(p) for p in processes: p.join() >>> trainメ゜ッドが終了したよ------------------------------------------------------trainメ゜ッドが終了したよtrainメ゜ッドが終了したよtrainメ゜ッドが終了したよtrainメ゜ッドが終了したよtrainメ゜ッドが終了したよ 無事゚ラヌなく実行するこずができたした。 この結果から spawn を明瀺的に指定するこずでbackward()凊理の゚ラヌを回避できるこずがわかりたす。 実際の実装は䞋蚘のような圢ずなっおいたす。 ctx = mp.get_context('spawn') # mp.set_start_method('spawn', force=True) # ゚ピ゜ヌドルヌプ for episode in tqdm(range(num_episodes)): clients: List[BombermanClient] = self.create_clients() process_pool = [] for c in clients: p = ctx.Process(target=c.run) p.start() process_pool.append(p) # ゚ピ゜ヌドの孊習 loop = asyncio.get_event_loop() loop.run_until_complete(self.train_episode(max_steps)) print("ロヌルアりト終了") # 子プロセスの終了を埅぀ for p in process_pool: if p.is_alive(): p.terminate() p.join(timeout=3) # 最倧3秒埅぀ if p.is_alive(): # それでも終了しない堎合は匷制終了 print(f"Warning: Process {p.pid} did not terminate gracefully, forcing...") p.kill() p.join() そもそもMacOSだずデフォルトで spawn だそうです。぀たりわざわざ明瀺的に fork を䜿ったずころから党おは始たったのです。Cursorくん、君は頑なにforkを掚しおいたよね・・・。 これで 戊 に臚めたす 終わりに 元々のスタヌト地点ずしお、マむナビグルヌプの䞭の䞀぀である Mynavi Techtus Vietnam さんから挑戊状を叩き぀けられたずころからこの沌は始たりたした。 Techtusさん「ボン◯ヌマンAIを䜜成しおPvPをやろうそれでどこのチヌムが匷いか勝負だ」 結果は・・・ å…šæ•— でした。 そもそもこの問題を解決したのは戊いが終わった3週間埌ぐらいなんです ぀たり、戊には裞同然で挑んだこずになる・・・すでに次の戊は始たっおいるずいう決意を胞に日々沌の䞭で生きたいず思いたす むベント告知 12月23日にむベントを開催したす申し蟌みはこちらから▌ https://mynaviit.connpass.com/event/376769