inflearn logo
知識共有
inflearn logo

2時間で完成する実践ハーネスエンジニアリング

AIでMVPを作ることは、もはや難しくありません。 しかし、ほとんどのプロジェクトはその次の段階で止まってしまいます。 👉 機能は作ったけれど 👉 開発が継続しません なぜこのようなことが起きるのでしょうか? 問題はコードではなく、 👉 AIが持続的に働ける「構造」がないからです。 --- この講義では、 すでに作成されたプロジェクトをベースに、 👉 AIが開発を続けていける構造を 👉 直接構築するプロセスを扱います --- 単にAIツールを使うのではなく、 * docs構造を作り * SSOTを定義し * チケット単位で開発を実行し * QAと反復構造まで繋げることで 👉 一つの「AI開発システム」として完成させます --- このプロセスを通じて 👉 人が直接コーディングしなくても 👉 開発が続いていく構造 つまり、 👉 AIをチームのように運用する開発システムを 👉 自ら作り、理解することができます --- この講義は 👉 自分のプロジェクトにすぐ適用できる構造を作りたい方 👉 AIで開発を始めたが、継続が難しかった方 👉 雰囲気でのコーディング(バイブコーディング)の先、次のステップへ進みたい方 のために構成されました。 --- 単に学ぶだけでなく、 👉 実行してみて 👉 実際に動作する構造を作り 👉 自身のプロジェクトに適用できる形で持ち帰る経験 を提供します。

難易度 初級

受講期間 無制限

Python
Python
cursor
cursor
ChatGPT
ChatGPT
AI Agent
AI Agent
Vibe Coding
Vibe Coding
Python
Python
cursor
cursor
ChatGPT
ChatGPT
AI Agent
AI Agent
Vibe Coding
Vibe Coding

受講後に得られること

  • SSOT(信頼できる唯一の情報源)に基づき、AIが継続的に開発を進める仕組みを直接構築します。

  • チケットベースの開発を通じて、一つのサービスを最後まで完成させる経験をします。

  • このような構造をハーネスエンジニアリングの観点から理解し、実務に適用することができます。


実務にすぐ適用できる
ハーネスエンジニアリングの手法を公開します。


#ハーネスエンジニアリング | #SSOT | #チケットベース開発 | #Claude/Cursor | #実践適用


もしかして、このような経験はありませんか?

AIが最初はうまく動いていたのに、要件を追加するにつれて、だんだんと的外れなコードを出すようになっている。

確かに同じ開発を依頼したのに、昨日と今日でAIの出力結果が違っていて戸惑っている。

AIでMVPは作ったものの、次の段階に進めずプロジェクトが放置された。

AIに任せればすべてうまくいくと思ったのに…
何が問題なのでしょうか?


なぜ?
AI開発を難しくする3つの理由

コンテキストが維持されない。

AIは文脈を長期的に記憶できないため、作業が積み重なるほど一貫性が失われます。

作業単位が明確ではない。

AIは曖昧なリクエストを自ら解釈するため、結果が毎回異なります。

検証と修正の段階がない。

検証と修正なしに開発だけを繰り返すと、AIは基準なしにコードを継ぎ足し続けることになります。


3つの問題の共通の原因は一つです。
AIが働ける構造がないということ。

したがって、AI開発を始める前に

AIの特性を考慮した環境設計が不可欠です。

AI開発の新しい基準

ハーネスエンジニアリング

ハーネスエンジニアリングとは、AIが安定して作業できるように
開発環境を設計することを意味します。



ハーネスエンジニアリング
実務にはどのように適用するのでしょうか?

理想的なハーネスエンジニアリングの設計手法は存在します。
しかし、理想的な環境と実務の現実の間には常にギャップがあります。

理想的な環境

  • 明確な要件に基づいて開発を開始する。

  • 最初からきれいな構造で始める。

  • 開発前に完璧な構造をあらかじめ決めておく。

実務の現実

  • 開発中にも要求事項は頻繁に変わる。

  • すでにレガシーコードが積み上がっている。

  • 最初から完璧な構造を作る時間はない。 ngay từ đầu.



レガシーな環境、頻繁に変わる要求事項...

なので、実務に適用する
ハーネスエンジニアリングは、これまでとは違ったものでなければなりません。


実務にすぐ適用可能な

チケットベースのハーネスエンジニアリング


チケットの生成とQAは人間が、残りの実装・分析・デプロイはAIが実行する方法です。
人間が基準と検証を担い、AIがチケット単位で実行するため、
安定性と柔軟性を両立させることができます。

SSOT

一貫した原則の定義

一つの基準文書があれば、作業が積み重なってもAIが一貫して作業を行います。

チケット設計

実行可能な作業単位

AIが処理できるサイズでタスクを定義すれば、成果物の品質が向上します。

反復ループ

開発→QA→修正→完了

チケットベースで一つのフローをAIと協業しながら反復する構造を作ります。


講義の核心

📚 講義で学ぶ核心内容

01

Agent-first 開発

AI Agent中心の開発フローへと転換します。

02

SSOTベースの構造

Markdownベースの単一真実の源(Single Source of Truth)によって、開発基準を統一します。

03

チケット中心の開発フロー

ChatGPTを活用してチケットを生成し、
Cursorを通じて自動実行される開発フローを構成します。

04

自動化されたQA & Done

分析レポートの作成から完了基準の検証まで
自動化された開発サイクルを構築します。

0505

持続可能な開発ループ

一度設定すれば繰り返しの使用が可能な
AIベースの開発システムを構築します。


ChatGPTを通じた企画、Cursorを活用した開発、Pythonベースの実行構造まで含まれた、実際のAI開発システムです。


🧩 この講義で使用する構成要素

  • ChatGPT (企画およびチケット生成)

  • Cursor (AIベースのコード生成および修正)

  • MarkdownベースのSSOT

  • Python / API 構造

  • MongoDB

  • Hugging Face Space デプロイ

  • Vercel デプロイ

核心は技術ではなく「構造」です。
この構造は どのような言語やスタックでもそのまま適用できます。

受講対象

🎯 このような方におすすめです。

✅ AIでサービスを作ったものの、開発が継続できない方

✅ ChatGPT、Cursorを使用しているが、結果が一定しない方

✅ 反復作業なしで開発を継続したい方

✅ AIを単なるツールではなく「開発リソース」として活用したい方


AIが働き続けられる仕組みを作る方法、Cách tạo ra cấu trúc để AI có thể làm việc liên tục,

AIエージェントベースの開発システムを
直接構築してみたい方におすすめします。

こんな方に
おすすめです

学習対象は
誰でしょう?

  • AIでMVPは作ったものの、その後の開発が続かずプロジェクトが止まってしまった経験がある方

  • GPTやCursorなどを活用しているものの、出力結果が安定せず、コンテキストが次第に混乱してしまうという問題を抱えている方

  • AIを単なるコード生成ツールではなく、実際の開発リソースとして活用したい開発者およびチーム

  • 既存のレガシープロジェクトにAIを導入してみたいが、どこからどのように始めればよいか分からず困っている方

前提知識、
必要でしょうか?

  • 必須の事前知識はありません。

  • Gitでリポジトリを作成し、コミットした経験があれば、よりスムーズに進められます。

  • 簡単なウェブサービスの構造(FE / BE)に関する理解があると役立ちます。

  • GPTやCursorなどのAIツールを一度でも使用した経験があれば望ましいです。

  • この講義は特定の技術ではなく、AIが開発を行う仕組みを扱います。

こんにちは
knodark74です。

キャリア認証

538

受講生

19

受講レビュー

4

回答

4.2

講座評価

2

講座

25年以上開発を続けてきたエンジニアとして、
自らAIでMVPを作っては壊す過程を繰り返し、
「AIが開発を継続できる構造」を構築してきました。

ChatGPT、Cursor、Pythonをベースに
企画 → 開発 → QA → デプロイまでつながる
「一人でも回るAI開発システム」を自ら設計し、運用しています。

単なるバイブコーディングではなく、
AIエージェントが持続的に開発を遂行できる構造を構築しており、
これを実際のサービスに適用して検証しています。

もっと見る

カリキュラム

全体

6件 ∙ (2時間 16分)

講座資料(こうぎしりょう):

授業資料
講座掲載日: 
最終更新日: 

受講レビュー

全体

10件

3.8

10件の受講レビュー

  • cjpark4915님의 프로필 이미지
    cjpark4915

    受講レビュー 3

    平均評価 5.0

    5

    67% 受講後に作成

    • sungjunyoo8480님의 프로필 이미지
      sungjunyoo8480

      受講レビュー 2

      平均評価 5.0

      5

      67% 受講後に作成

      • seop76724님의 프로필 이미지
        seop76724

        受講レビュー 3

        平均評価 4.3

        5

        67% 受講後に作成

        • ysw0814955님의 프로필 이미지
          ysw0814955

          受講レビュー 14

          平均評価 3.7

          修正済み

          1

          83% 受講後に作成

          ハーネスエンジニアリングというよりは、SSOTの講義と言うべきではないでしょうか…。 ハーネスを狭義で見れば間違いではありませんが…。 かといってSSOTの講義と言うにも、要素ごとに何かしら不足していると感じます。 カンファレンスでの断片的な発表事例程度なら適当かもしれませんが、講義を通じて誰かに知識を伝える意図は全く感じられない講義のようです。 画面も正直小さすぎて、何も見えませんね。 まず、講義資料としてアップロードされた各mdファイルについて。 核心はssot.mdですが、階層別の多重統制がメリットである一方で、コンテキスト(つまりトークン)の使用増大により、コスト効率が悪く高くつくという点。MVP以降、SSOTを通じて既存の構造をそのまま引き継ぐとはいえ、過度な技術的負債を誘発し、後のリファクタリングを困難にするという点。SSOT + SDD + TDDを繋げるハーネスエンジニアリングへと続く「森」ではなく、「一本の木の枝一つ」を伝えながら、過剰にドキュメントを作成させたり、あちこち行き来させて混乱を招き、ミスをしやすいように作られている点など、メリットよりもデメリットの方が多い気がします。 かといって、スプリンター、エピック、ストーリー、タスクなどのチケット単位に関する説明もなく(こうした概念を知っているなら、そもそもこの講義を受講する理由はないでしょう)、あまりにも不親切で断片的な事例を通じて「ハーネスエンジニアリング」と称している講義のようです。

          • knodark74
            知識共有者

            フィードバックありがとうございます。先ほどの回答をより具体的に修正いたします。 画面の視認性の問題、そしてドキュメント構造の特性上、トークン消費が高くなる点は実際のトレードオフであり、講義で十分に扱いきれていなかったのは事実です。 SSOT設計とチケット設計に関する説明はセクション2で扱っていますが、期待されていた深さとは異なっていたようです。 技術負債の部分については少し認識が異なります。講義の流れは、MVPをCursorで構造分析させ、その結果をもとにSSOTを修正した後、チケットベースの開発へとつなげていく方式です。既存の構造をそのまま乗せるのではなく、分析後に精査して反映する構造になっています。ただ、その流れが講義の中で十分に伝わっていなかったのは事実です。 sprint/epic/ticketの概念は前提知識として設定した講義であるため、該当する背景知識なしで受講されると不親切に感じられる可能性があります。講義紹介で対象となる受講生をより明確にすべきでした。 具体的にご指摘いただいたおかげで、次回はより明確なものを作ることができそうです。

        • nkhwi9746님의 프로필 이미지
          nkhwi9746

          受講レビュー 5

          平均評価 5.0

          5

          67% 受講後に作成

          似ている講座

          同じ分野の他の講座を見てみましょう!

          新規会員登録で25%OFF

          ¥5,286

          25%

          ¥7,046