[秋夕特集] シリコンバレーの開発者が教えるLLM評価ハーネスエンジニアリング
Hong
LLMを活用したサービスを作る中で、プロンプトやモデルを変更した後、以前より回答の品質が低下したかどうかを確認するのが難しかった経験があるなら、この講義が解決策になるかもしれません。自分で評価基準を作成し、変化した回答を自動的に見つけ出す方法を学びます。
初級
JavaScript, TypeScript, Business Productivity
Swaggerドキュメントを修正し、APIスペックを合わせ、フロントエンドと繰り返しコミュニケーションを取っていると、「なぜ同じことを二度も繰り返しているのだろう?」という悩みに直面することがあります。私自身も実務で似たようなもどかしさを多く感じ、その過程でGraphQLを深く使いながら、データ中心の設計手法に関心を持つようになりました。この講義では、単なるGraphQLの文法ではなく、実際のサービスでどのような問題を解決するために登場したのか、そしてResolverの構造、N+1問題、Federationといった実務的な課題を共に扱います。開発者間のコミュニケーションコストを削減し、より柔軟なAPI構造を設計する流れを自然に習得できるよう構成しました。
受講生 90名
難易度 入門
受講期間 無制限
学習した受講者のレビュー
5.0
warna
入門用に軽く聴くのにちょうど良さそうですね。ありがとうございます!
5.0
Deck
GraphQLが気になるなら、入門としておすすめです。私も全く何も知らない状態でしたが、この講義を受けてある程度感覚が掴めたので、実務に適用している段階です。 ありがとうございます。
単にクエリを作成するレベルにとどまらず、実際のサービスでGraphQLスキーマをどのように設計すべきかという感覚を掴むことができます。「なぜこのような構造に分けるのか?」を理解できるようになります。
REST APIで繰り返されていたオーバーフェッチ(Over Fetching)やアンダーフェッチ(Under Fetching)の問題を直接解決しながら、フロントエンドとバックエンドがデータを中心にどのようにしてより柔軟に協業できるかを経験することになります。
Resolverの構造化、DataLoader、N+1問題の解決戦略まで、実務で必ず直面するパフォーマンスの問題を直接扱うことで、「動くGraphQL」ではなく「運用可能なGraphQL」を作れるようになります。
Swaggerドキュメントを別途管理することで発生していたスペック不一致の問題の代わりに、イントロスペクション(Introspection)ベースの自己文書化構造を理解し、APIドキュメント化の方式そのものを新たな視点で見つめ直すことになります。
単純なCRUDレベルを超えて、Federation、Subscription、認証処理といった高度なパターンまで学習することで、実際の大規模サービス環境においてGraphQLをどのように拡張していくのか、その流れを理解できるようになります。
❗以下の内容は実際の会話内容です。
😄 Hong : 会社で本当に、ただAPIを一つ開発する時もすごく面倒なのが、Swaggerをすごく要求されるんだ... そのフォーマットを合わせて、スペックが変わるたびに一緒に修正しなきゃいけないから、本当に面倒だよ。
😄 Hong : 毎回感じることなんだけど… Swaggerもやらなきゃいけないし、ドキュメント作成もしなきゃいけないし、なぜ重複した作業を二度もするんだろう 単に開発者同士のコミュニケーションに限定するなら、個人的にドキュメントというものがそれほど重要なのか分からないんだけど
😄 Hong : ただgRPCみたいに.protoファイルを見てDDDっぽく開発すればいいんじゃないかな、もどかしいよ
😁Kakao面接官(開発者) : 成長したな、凡夫よ... wwwwww 冗談だよ、実際まあ、あながち間違いでもない気がするし
😁Kakao面接官(開発者) : 僕も以前はただみんながやってるから、それで同じようにやってたんだけど、やりながらも"これを何でこうするんだろう??"っていう疑問はあったんだ。そうやって他のことを追求していくうちに、成長できた気がするんだけど?
😁 Toss 開発者 : wwww Hong 凡夫よ… wwwww そのために GraphQL があるじゃん。Facebook が作ったんだっけ?
😁Kakao面接官(開発者) : うん、だから僕も勉強しているうちにそれに関連して結構使ってみたんだけど、Hongが言ったようにgRPCと同じだよ。実質的にHTTP通信を規格化して進めるという感じだね
😁Kakao面接官(開発者) : これを僕が教えてあげるよwwww 話が出たついでに、久しぶりにGraphQLの古参としてちょっと扱ってみたくなったんだ
数多くのサービスがデータを中心に連携する環境において、私たちは単なるREST APIの設計を超えて、「データをどのように伝達し、消費するのか」そのものについて考えるようになります。
バックエンドではすでに用意されたデータを返しているものの、フロントエンドでは不要なフィールドまで受け取ってしまったり、逆に一つの画面を構成するために複数のAPIを何度も呼び出さなければならないといった状況が繰り返されています。
そうなると、自然とこのような悩みが生まれてきます。
なぜ必要なデータだけをリクエストできないのだろうか??
APIバージョンが増え続ける構造は、本当に正しいのだろうか??
Swaggerの仕様書と実際のレスポンス構造が乖離する問題は、なぜ繰り返されるのだろうか??
フロントエンドとバックエンドがデータを中心に、もっと柔軟に連携することはできないだろうか??
GraphQLは、まさにこのような問題意識から出発しています。
単にRESTを代替する技術ではなく、クライアントが必要なデータを直接定義して取得する方式で、APIの役割自体を再設計したアプローチです。実際の現場でなぜGraphQLが登場することになったのか、
どのような状況でRESTより強力なのかをお伝えし、単純なCRUDレベルを超えて、Schema設計、Resolver構造化、N+1問題の解決、DataLoaderの活用、Federation、Subscription、認証処理など、実務で必ず直面する構造的な問題も一緒に見ていきます。
「GraphQLの文法を知っている開発者」ではなく、"データ中心のAPI構造を設計できる開発者”へと成長する過程となるよう、この講義を通じてサポートいたします。 🚀
TypeScript, JavaScript, GraphQL, MSA, 国費支援ブートキャンプ
従来のRESTベースの構造では、画面ごとに必要なデータが異なるほど、APIの数も増えていきます。
Web、モバイル、管理画面(Admin)ページがそれぞれ異なるデータを要求し始めると、結局バックエンドは似たようなAPIを追加し続けることになり、構造はますます複雑になります。
しかし、GraphQLは少し異なるアプローチをとります。
クライアントが「どのようなデータが必要か」を直接定義し、サーバーはそのリクエストに合わせて必要なデータだけを組み合わせて返却します。つまり、サーバーが画面を基準にAPIを設計するのではなく、データ構造自体を中心に動作するようになるのです。
また、GraphQLは単に一つのデータベースだけを見ているわけではありません。
User Database、Post Database、外部API、Commentシステムなど、異なるデータソースを一つのスキーマの下で有機的に統合できます。そのおかげで、フロントエンドは内部構造を知らなくても、単一のエンドポイントだけで必要なデータを取得できるようになります。
お伝えしましたが、この講義では単にQueryの文法だけを説明するのではありません。
実際のResolverがどのような役割を果たすのか、
なぜDataLoaderが必要なのか、
N+1問題がなぜ発生するのか、
サービスの規模が大きくなるにつれてSchemaをどのように進化させるべきかまで、併せて扱います。
単に「GraphQLの使い方」を学ぶのではなく、複雑なサービス環境においてデータをどのように設計し、つなげるべきかについての考え方を共に身につけることになるでしょう。🚀
多くの開発者が最初は、GraphQLを単に「RESTより便利なAPI技術」という程度で捉えてアプローチします。
しかし、実際のサービス環境では、思った以上に様々な問題に直面することになります。
Resolverが増えるほど複雑になる呼び出し構造、
何気なく作成したクエリ一つによって発生するN+1問題
過度に肥大化するスキーマ、
権限処理とキャッシュ戦略、
MSA環境におけるフェデレーション設計まで
結局重要なのは「GraphQLの文法」ではなく、データフローをどのように設計するかという観点です。 🚀
Prismaを活用したデータマイグレーションおよびGUI
データベースの最も致命的な問題 N+1問題を防止するためのDataLoaderパターン
非同期およびイベント通信(PubSub)のためのサブスクリプションパターン
12年目のバックエンドサーバー開発者として、カカオでサーバー開発を行いながら面接官としても活動しているChoiと申します。
Hongとは以前Conferenceで縁があり、講義活動の中盤からずっと一緒に積極的に参加しながら、多様なテーマで講義を作ってきた経歴があります。このように講義を作りながら、様々な方々と対話し、コミュニケーションを取ることが、私の開発者人生において大きな助けとなり、多様な視点を学べる時間であると考え、より多様なテーマを扱うために努力しています。
いわゆる大企業という一つの経歴が、優れた開発者であることを証明するわけではないと思いますが、少なくとも一般的なプラットフォームに比べて、より多くのトラフィックや経験を得られると考えています。こうした部分を常に講義に盛り込みながら、お伝えしていきたいと思います。
[現] カカオ本社 サーバー開発者
[前] ソウル4年制コンピュータ工学専攻
OS :
Apple M3 Air
Node : v25.5.0
IDE : VsCode
学習対象は
誰でしょう?
Swaggerを修正してAPIドキュメントを合わせる作業が繰り返されるたびに、「なぜ同じことを二度もやっているんだろう?」と感じるバックエンド開発者
画面一つを作成するために複数のREST APIを呼び出し、フロントエンドとのデータスペック調整に疲れ果てている開発者
GraphQLの文法は少し見たが、実際のResolver構造や実務での設計手法についてはまだピンとこない開発者
MSA環境や大規模サービス構成において、データフローをどのように接続し管理すべきか悩んでいるサーバー開発者
単なる技術の使い方よりも、「なぜこのような技術が登場し、どのような問題を解決しようとしているのか」を理解しながら成長したい開発者
前提知識、
必要でしょうか?
初心者のための講座です!難易度が低いため、事前知識は必要ありません。
インフラン認証
キャリア認証
10,395
受講生
647
受講レビュー
171
回答
4.8
講座評価
34
講座
家でだらだら過ごしていたところ、開発に興味を持ち勉強を始め、現在は板橋(パンギョ)でプラットフォームサーバーの開発を担当しています。私が勉強してきた方法や、実務で直面する可能性のある様々な問題点とその解決策を皆さんに提供したいと思い、知識共有者としての活動を続けています。
講義は私一人の知識だけで作られるものではありません。すべての講義には、共に作り上げてくださる方々がいます。
Tossの開発者からの推薦で合流されたシリコンバレーの開発者 Waddy, người đã tham gia theo lời giới thiệu của một nhà phát triển từ Toss
[知識共有者の経歴]
[前] サンドボックスIP関連ブロックチェーン開発者
[前] メタバースバックエンドエンジニア
[現] 板橋(パンギョ)でベテランになりつつあるサーバー開発者
[インタビュー履歴]
[その他のお問い合わせ]
[公式サイト]
全体
16件 ∙ (3時間 58分)
講座資料(こうぎしりょう):
全体
2件
5.0
2件の受講レビュー
受講レビュー 13
∙
平均評価 5.0
5
GraphQLが気になるなら、入門としておすすめです。私も全く何も知らない状態でしたが、この講義を受けてある程度感覚が掴めたので、実務に適用している段階です。 ありがとうございます。
良い評価を残していただきありがとうございます。良い一日をお過ごしください。
受講レビュー 13
∙
平均評価 5.0
知識共有者の他の講座を見てみましょう!
同じ分野の他の講座を見てみましょう!
期間限定セール、あと1日日で終了
¥53,130
30%
¥9,633