実践OpenAI SDK:中級者のためのAIエージェントワークフローとサービス構築
YoungJea Oh
¥7,046
初級 / AI, ChatGPT, prompt engineering, LLM
5.0
(2)
単なるチャットボットを超えたエージェントの実装に行き詰まっていませんか?私が直接経験した試行錯誤と公式ドキュメントに基づいたノウハウで、実務に即座に適用可能な中級エージェント構築法をお教えします。
初級
AI, ChatGPT, prompt engineering
AIでMVPを作ることは、もはや難しくありません。 しかし、ほとんどのプロジェクトはその次の段階で止まってしまいます。 👉 機能は作ったけれど 👉 開発が継続しません なぜこのようなことが起きるのでしょうか? 問題はコードではなく、 👉 AIが持続的に働ける「構造」がないからです。 --- この講義では、 すでに作成されたプロジェクトをベースに、 👉 AIが開発を続けていける構造を 👉 直接構築するプロセスを扱います --- 単にAIツールを使うのではなく、 * docs構造を作り * SSOTを定義し * チケット単位で開発を実行し * QAと反復構造まで繋げることで 👉 一つの「AI開発システム」として完成させます --- このプロセスを通じて 👉 人が直接コーディングしなくても 👉 開発が続いていく構造 つまり、 👉 AIをチームのように運用する開発システムを 👉 自ら作り、理解することができます --- この講義は 👉 自分のプロジェクトにすぐ適用できる構造を作りたい方 👉 AIで開発を始めたが、継続が難しかった方 👉 雰囲気でのコーディング(バイブコーディング)の先、次のステップへ進みたい方 のために構成されました。 --- 単に学ぶだけでなく、 👉 実行してみて 👉 実際に動作する構造を作り 👉 自身のプロジェクトに適用できる形で持ち帰る経験 を提供します。
受講生 69名
難易度 初級
受講期間 無制限
SSOT(信頼できる唯一の情報源)に基づき、AIが継続的に開発を進める仕組みを直接構築します。
チケットベースの開発を通じて、一つのサービスを最後まで完成させる経験をします。
このような構造をハーネスエンジニアリングの観点から理解し、実務に適用することができます。
学習対象は
誰でしょう?
AIでMVPは作ったものの、その後の開発が続かずプロジェクトが止まってしまった経験がある方
GPTやCursorなどを活用しているものの、出力結果が安定せず、コンテキストが次第に混乱してしまうという問題を抱えている方
AIを単なるコード生成ツールではなく、実際の開発リソースとして活用したい開発者およびチーム
既存のレガシープロジェクトにAIを導入してみたいが、どこからどのように始めればよいか分からず困っている方
前提知識、
必要でしょうか?
必須の事前知識はありません。
Gitでリポジトリを作成し、コミットした経験があれば、よりスムーズに進められます。
簡単なウェブサービスの構造(FE / BE)に関する理解があると役立ちます。
GPTやCursorなどのAIツールを一度でも使用した経験があれば望ましいです。
この講義は特定の技術ではなく、AIが開発を行う仕組みを扱います。
キャリア認証
538
受講生
19
受講レビュー
4
回答
4.2
講座評価
2
講座
25年以上開発を続けてきたエンジニアとして、
自らAIでMVPを作っては壊す過程を繰り返し、
「AIが開発を継続できる構造」を構築してきました。
ChatGPT、Cursor、Pythonをベースに
企画 → 開発 → QA → デプロイまでつながる
「一人でも回るAI開発システム」を自ら設計し、運用しています。
単なるバイブコーディングではなく、
AIエージェントが持続的に開発を遂行できる構造を構築しており、
これを実際のサービスに適用して検証しています。
全体
6件 ∙ (2時間 16分)
講座資料(こうぎしりょう):
全体
10件
3.8
10件の受講レビュー
受講レビュー 3
∙
平均評価 5.0
受講レビュー 2
∙
平均評価 5.0
受講レビュー 3
∙
平均評価 4.3
受講レビュー 14
∙
平均評価 3.7
修正済み
1
ハーネスエンジニアリングというよりは、SSOTの講義と言うべきではないでしょうか…。 ハーネスを狭義で見れば間違いではありませんが…。 かといってSSOTの講義と言うにも、要素ごとに何かしら不足していると感じます。 カンファレンスでの断片的な発表事例程度なら適当かもしれませんが、講義を通じて誰かに知識を伝える意図は全く感じられない講義のようです。 画面も正直小さすぎて、何も見えませんね。 まず、講義資料としてアップロードされた各mdファイルについて。 核心はssot.mdですが、階層別の多重統制がメリットである一方で、コンテキスト(つまりトークン)の使用増大により、コスト効率が悪く高くつくという点。MVP以降、SSOTを通じて既存の構造をそのまま引き継ぐとはいえ、過度な技術的負債を誘発し、後のリファクタリングを困難にするという点。SSOT + SDD + TDDを繋げるハーネスエンジニアリングへと続く「森」ではなく、「一本の木の枝一つ」を伝えながら、過剰にドキュメントを作成させたり、あちこち行き来させて混乱を招き、ミスをしやすいように作られている点など、メリットよりもデメリットの方が多い気がします。 かといって、スプリンター、エピック、ストーリー、タスクなどのチケット単位に関する説明もなく(こうした概念を知っているなら、そもそもこの講義を受講する理由はないでしょう)、あまりにも不親切で断片的な事例を通じて「ハーネスエンジニアリング」と称している講義のようです。
フィードバックありがとうございます。先ほどの回答をより具体的に修正いたします。 画面の視認性の問題、そしてドキュメント構造の特性上、トークン消費が高くなる点は実際のトレードオフであり、講義で十分に扱いきれていなかったのは事実です。 SSOT設計とチケット設計に関する説明はセクション2で扱っていますが、期待されていた深さとは異なっていたようです。 技術負債の部分については少し認識が異なります。講義の流れは、MVPをCursorで構造分析させ、その結果をもとにSSOTを修正した後、チケットベースの開発へとつなげていく方式です。既存の構造をそのまま乗せるのではなく、分析後に精査して反映する構造になっています。ただ、その流れが講義の中で十分に伝わっていなかったのは事実です。 sprint/epic/ticketの概念は前提知識として設定した講義であるため、該当する背景知識なしで受講されると不親切に感じられる可能性があります。講義紹介で対象となる受講生をより明確にすべきでした。 具体的にご指摘いただいたおかげで、次回はより明確なものを作ることができそうです。
受講レビュー 5
∙
平均評価 5.0
同じ分野の他の講座を見てみましょう!
新規会員登録で25%OFF
¥5,286
25%
¥7,046