ソフトウェア開発 on KnightLiブログ

OpenClaw 作者 Peter Steinberger は AI ソフトウェア開発をどう見ているのか：OpenClaw から閉ループ開発へ

Sun, 17 May 2026 20:02:26 +0800

Peter Steinberger の経歴は、AI ソフトウェア開発で何が変わっているのかを見るうえでよい材料になる。

彼は「AI で突然注目された新人」ではない。OpenClaw の前から、PSPDFKit の創業者として PDF レンダリング、文書処理、開発者ツールに長く取り組んできた。この種のプロダクトは、コンセプトだけでは勝てない。性能、互換性、API 設計、企業顧客、長期保守に向き合う必要がある。

そのため、Steinberger が後に AI ツールで OpenClaw を作り、AI Agent、個人自動化、AI coding について語ったとき、重要なのは「一人で大量のコードを書いた」ことだけではない。より面白いのは、長年のソフトウェア工学経験と新世代の AI coding agent を組み合わせ、開発プロセスをどう捉え直したかだ。

AI coding は魔法のボタンではない

AI coding の議論は、よく二つの極端に分かれる。

一方は、AI はすでにコードを書けるのでプログラマーは不要になる、と言う。

もう一方は、AI が書くコードは信頼できず、本当のエンジニアリングは人間が手で書くべきだ、と言う。

Steinberger の経験は第三の見方に近い。AI はソフトウェア開発の操作単位を変えるが、エンジニアリング判断を消すわけではない。

従来、開発者の仕事は主に「コードを編集する」ことを中心に回っていた。要求分解、アーキテクチャ判断、実装、テスト、バグ修正は、すべて人間によるコード変更を軸にしていた。

AI coding agent が入ると、開発者はだんだん実行システムを管理する存在に近づく。

目標を説明する。
コンテキストを与える。
境界を決める。
agent にコードを変更させる。
テストとチェックを実行する。
結果に基づいて反復する。

これは単にキーボードをモデルに渡すことではない。人間の役割を「すべての行を自分で打つ」ことから、「方向を定義し、フィードバックを設計し、結果を判断する」ことへ移すものだ。

なぜ彼は vibe coding という呼び方を好まないのか

Steinberger をめぐる議論でよく出る言葉に vibe coding がある。

この言葉はもともと、開発者が自然言語でアイデアを説明し、AI に大量のコードを生成させ、実行結果とフィードバックで調整していく新しい開発スタイルを指していた。

しかし Steinberger は、この言葉を全面的には受け入れていない。公開記事では、彼が vibe coding をやや軽蔑的な表現になりやすいと見ていることが紹介されている。AI 支援開発を「感覚で適当に生成する」もののように見せ、背後にある技能、判断、経験を見落とすからだ。

この批判には筋がある。

本当に有効な AI coding は、適当に一文を入力してモデル出力を信じることではない。必要なのは次のような能力だ。

曖昧な要求を実行可能なタスクに分解する。
モデルが目標を誤解したかどうかを見抜く。
テストと受け入れ基準を設計する。
コード構造が長期保守に影響するか判断する。
いつ生成を止めて人間のレビューに切り替えるべきか分かる。

つまり、AI はコードを書く摩擦を下げるが、システムを理解する責任を下げるわけではない。

鍵は閉ループにある

Steinberger のインタビューや記事でよく要約される考え方の一つが「ループ」だ。

AI にコードを生成させるだけなら、開ループである。

AI にコードを生成させ、実行させ、エラーを読み、問題を修正し、再びテストを走らせるなら、閉ループに近づく。

この差は非常に大きい。

開ループ生成は、表面上は使えそうなソフトウェアを作りやすい。ページは開き、機能はあるように見え、コードも多い。しかし実際の環境に入ると、状態管理、権限、例外処理、境界条件、デプロイの問題が出てくる。

閉ループ開発では、出力がフィードバックによって制約される。もっとも単純なループは次の通りだ。

目標を明確に書く。
AI にコードを変更させる。
テスト、型チェック、lint、ビルドを自動実行する。
エラーを AI に返す。
通るまで繰り返す。
最後に人間が重要経路をレビューする。

AI ソフトウェア開発が本当に効率を上げるのはここだ。モデルが一度で正解を書くからではない。生成、検証、修復のサイクルに高速に参加できるからだ。

経験が多いほど AI を使いやすい

AI coding で生まれやすい誤解の一つは、「経験はもう重要ではない」というものだ。

Steinberger の事例はむしろ逆を示している。経験はより重要になる。ただし役割が変わる。

経験あるエンジニアは、次の判断がしやすい。

どのタスクを agent に渡すべきか。
どのモジュールに先にテストを書くべきか。
どの変更はリスクが高く、AI に広範囲リファクタを任せるべきではないか。
どの生成コードは見た目だけ妥当なのか。
どの問題はパッチではなくアーキテクチャ調整で解くべきか。

AI は大量の候補案を生成できる。しかし候補が多いほど判断力が必要になる。経験が少ない人は「動いた」ことに惑わされやすい。経験ある人は、保守できるか、拡張できるか、安全境界を壊さないか、問題が起きたときに定位できるかを問う。

だから AI coding agent は、ソフトウェア工学を単なるチャットにはしない。一部の実行労働を外に出しつつ、計画、レビュー、検証、取捨選択の重要性を増幅する。

OpenClaw の意味はプロジェクトそのものにとどまらない

OpenClaw が注目されたのは、単にオープンソース AI agent だからでも、成長が速かったからでもない。

それは一つのシグナルでもある。開発者は、AI に単に質問へ答えてほしいのではなく、実際のツールに接続し、実際の行動を完了してほしいと思い始めている。

従来のチャットボットは会話欄の中にとどまる。コードを説明し、下書きを書き、助言はできるが、多くの場合、人間がコピー、貼り付け、ソフトウェア起動、コマンド実行を行う必要がある。

Agent の方向性は、モデルをツールにつなぐことだ。

ファイルシステム。
ブラウザ。
ターミナル。
メール。
カレンダー。
第三者サービス。
プロジェクトリポジトリ。

モデルがこれらのツールを使えるようになると、ソフトウェア開発の境界が変わる。AI は単なる「コード補完」ではなく、プロジェクト読解、タスク分解、ファイル編集、テスト実行、PR 整理、ワークフロー自動化に関わるようになる。

Steinberger が OpenAI に加わったことで注目された理由もここにある。彼は一人の開発者の物語だけではなく、個人 agent がデモから日常業務へ進むというプロダクト方向を示している。

普通の開発者にとっての意味

普通の開発者にとって、Steinberger の経験をそのまま再現できるとは限らない。

誰もが複数の agent を同時に管理できるわけではない。すべてのプロジェクトが高強度の AI 生成に向くわけでもない。すべてのチームが「まず生成し、すばやく反復する」速度を受け入れるわけでもない。

それでも学べることはいくつかある。

第一に、タスクを明確に書く。

AI は曖昧な目標に敏感だ。「最適化して」と言うと、スタイル、構造、機能、ロジックまで変えるかもしれない。「ログイン失敗時のエラーメッセージを英語から中国語へ変更し、認証フローは変えない」と言えば、結果はより制御しやすい。

第二に、検証コマンドを固定する。

テストもビルドコマンドも lint もないプロジェクトでは、AI はループを作りにくい。npm test、go test ./...、pytest、hugo のような基本的なコマンドだけでも、目視確認だけよりはずっとよい。

第三に、変更範囲を制御する。

一度に一つのモジュール、一つの bug、一つのページだけを AI に扱わせる方が、「プロジェクト全体をリファクタして」と頼むより通常は信頼できる。

第四に、人間のレビューを残す。

認証、決済、権限、データ削除、デプロイスクリプト、データベース移行、セキュリティ設定では、コードが AI 生成だからといってレビュー基準を下げてはいけない。

第五に、prompt と失敗パターンを振り返る。

AI がある種のタスクをよく誤解するなら、その制約をプロジェクトルール、agent instructions、skill ファイルに書く。AI coding 能力はモデルだけでなく、周囲に作る作業環境からも生まれる。

AI ソフトウェア開発はどこへ向かうのか

Steinberger の物語は、AI ソフトウェア開発が「コードを書く支援」から「ソフトウェア生産フローを組織する」方向へ進んでいることを示している。

初期の AI coding ツールの価値は、関数補完、エラー説明、テンプレート生成が中心だった。今の変化は、agent がファイルをまたいで作業し、ツールを呼び出し、チェックを実行し、フィードバックに基づいて修正を続けられることだ。

そこからいくつかの流れが見えてくる。

第一に、個人開発者の生産上限は上がる。

一人でより多くのプロトタイプ、スクリプト、社内ツール、小型プロダクトを進められる。ただし生産量が増えることは品質が自動で上がることではない。生成が速いほど検証が重要になる。

第二に、プロジェクト構造がより重要になる。

コードが明確で、テストがはっきりしていて、ドキュメントが整っているほど、AI は正しく変更しやすい。混乱したプロジェクトは人間にも AI にも難しい。

第三に、ソフトウェアエンジニアはワークフロー設計者に近づく。

今後重要なのは、ある言語を書けるかどうかだけではない。要求、コンテキスト、ツール、テスト、デプロイ、権限を制御可能なループに組み立てられるかだ。

第四に、セキュリティ境界はより敏感になる。

Agent が何かを実行できるなら、間違ったことも実行できる。ファイルを読み、コマンドを実行し、サービスへアクセスできるなら、権限、監査、ロールバックは AI 開発環境の基盤になる。

まとめ

Peter Steinberger の AI ソフトウェア開発観で最も価値があるのは、「AI がどれだけコードを生成したか」ではない。彼が示した新しい開発姿勢だ。

人間はエディタ内で一行ずつ入力するだけではなくなりつつある。目標を設計し、agent を管理し、フィードバックループを作り、結果をレビューし、システムを調整する。コードは今も重要だが、労働の唯一の中心ではなくなっている。

従来のソフトウェア開発が「コードを正しく書く」ことを重視していたとすれば、AI ソフトウェア開発は「システムが検証可能に正しい結果を継続して出す」ことをより重視するようになる。

これは単にエンジニアリングのハードルを下げる話ではない。能力の形を変える話だ。手作業の実装から、タスク分解、コンテキスト管理、ツール編成、自動検証、最終判断へ移っていく。

参考資料

Karpathy の 65 行の CLAUDE.md：AI コーディングで三つの典型的なミスを減らす

Sun, 19 Apr 2026 18:27:23 +0800

最近、AI コーディングに関する GitHub プロジェクトが注目を集めている。中心にあるのは複雑なコードではなく、およそ 65 行の CLAUDE.md ファイルだ。このプロジェクトが多くの star を集めた理由は、技術実装の複雑さではない。AI にコードを書かせるとき、多くの人が繰り返し遭遇する問題をうまく捉えているからだ。

背景には、Andrej Karpathy による AI コーディングへの観察がある。Karpathy は AI 分野で大きな影響力を持つ教育者でありエンジニアだ。スタンフォード大学の博士で、OpenAI の初期にも関わり、Tesla では Autopilot の視覚システムを担当した。その後も大規模モデル、教育、AI ツールについて発信を続けているため、彼がプログラミング手法の変化について語ると、多くの開発者が注目する。

彼は、Claude Code を数週間使ったあと、自分のプログラミングスタイルが大きく変わったと述べている。以前はおよそ 80% を手書きし、20% を AI に補助させていた。今は 80% を AI に書かせ、自分は 20% を修正する感覚に近いという。自然言語で LLM に何を書くべきか伝えるので、「英語でプログラミングしている」ようなものだと表現している。

一方で、彼は AI コーディングにありがちな問題も指摘している。

01 誤った仮定

一つ目の問題は、モデルがユーザーの代わりに勝手な仮定を置き、その仮定に沿って書き進めてしまうことだ。モデルは必ずしも自分の混乱を管理しないし、要件が曖昧なときに立ち止まって質問するとも限らない。

たとえばユーザーが「ユーザーのエクスポート機能を追加して」とだけ言った場合、モデルは全ユーザーを出力する、JSON 形式にする、ローカルファイルに書き出す、権限や項目は確認不要だ、と勝手に決めるかもしれない。コードが完成してから、ユーザーはモデルの理解が実際のシナリオとずれていたことに気づく。

よりよい進め方は、不確かな点を先に列挙することだ。全ユーザーを出力するのか、フィルタ後の結果なのか。ブラウザでダウンロードするのか、バックグラウンドジョブなのか。必要な項目は何か。データ量はどれくらいか。権限制御はあるのか。こうした点を確認しないまま速く書いても、ずれが大きくなるだけだ。

02 過度な複雑化

二つ目の問題は、モデルが簡単な問題を複雑にしがちなことだ。一つの関数で済む問題に対して、抽象クラス、ストラテジーパターン、ファクトリーパターン、設定レイヤー、将来使うかもしれない拡張ポイントを山ほど追加することがある。

こうしたコードは一見エンジニアリングされているように見えるが、実際には保守コストを増やす。AI は大量の構造を素早く生成するのが得意だが、その構造が本当に必要かを常に判断できるわけではない。その結果、100 行で済むタスクが 1,000 行に膨らむ。

判断基準はシンプルだ。経験あるエンジニアがその変更を見て、過剰設計だと感じるかどうか。答えが yes なら、余分な層を削り、今の問題を解くために必要な最小限のコードに戻すべきだ。

03 付随的な被害

三つ目の問題は、モデルが十分に理解していないコードを変更したり削除したりすることだ。小さな bug を直している途中で、ついでにコメントを変えたり、フォーマットを整えたり、未使用に見える import を消したり、現在のタスクと無関係なロジックにまで手を入れることがある。

こうした「ついでの改善」は危険だ。変更範囲を広げ、レビューを難しくするからだ。ユーザーは空の email でバリデータが落ちる問題だけを直したいのに、モデルが email 検証を強化し、ユーザー名検証を追加し、ドキュメント文字列まで書き換えると、どの行が挙動を変えたのか分かりにくくなる。

より安全な原則は、必要なコードだけを変更し、自分の変更によって生まれた問題だけを片付けることだ。もともと存在していた dead code、フォーマットの問題、歴史的な負債は、明示的に依頼されていない限り触らない。必要なら一言指摘するだけでよい。

04 不満を CLAUDE.md に変える

Karpathy の見解が広く共有されたあと、開発者の Forrest Cheung は賢いことをした。これらの不満を、実行可能な行動指針として整理し、CLAUDE.md ファイルに書き込んだのだ。

このプロジェクトには複雑なコードはない。重要なのは、AI コーディングで問題が起きやすい部分を、明確な作業ルールに変えたことだ。大きく四つの原則にまとめられる。

一つ目は、書く前に考えること。黙って仮定しない。混乱を隠さない。要件に複数の解釈があるなら列挙する。より簡単な案があるなら伝える。確認が必要なら質問し、反論すべきときは反論する。

二つ目は、シンプルさを優先すること。求められていない機能を追加しない。一度しか使わないコードを抽象化しない。余計な設定を増やさない。ほぼ起きないケースのために大量の防御コードを書かない。50 行で済むなら 200 行にしない。

三つ目は、正確に変更すること。すべての変更行は、ユーザーの依頼に直接結びついているべきだ。近くのコードをついでに改善しない。壊れていないものをリファクタリングしない。できるだけ既存プロジェクトのスタイルに合わせる。

四つ目は、目標駆動で進めること。モデルに曖昧な指示だけを渡すのではなく、検証可能な成功基準を与える。たとえば「bug を直す」は「bug を再現するテストを書き、それを通す」にできる。「バリデーションを追加する」は「不正入力のテストを書き、それを通す」にできる。成功基準が明確なほど、モデルは完了に向けて自分でループしやすくなる。

05 なぜ広まったのか

このプロジェクトが広まったのは、内容が難解だからではない。実際の開発に近いからだ。

AI にコードを書かせたことがある人の多くは、似た場面を経験している。モデルが自信満々に要件を誤解する。コードがどんどん複雑になる。触るべきでない場所を変更する。CLAUDE.md の価値は、こうした経験をプロジェクトに置ける協作ルールに変えたことにある。

導入の敷居も低い。複雑な連携は不要で、一つのファイルから始められる。Karpathy 本人の影響力に加え、プロジェクト内に実践的な比較例があるため、Claude Code ユーザーや AI コーディングコミュニティの間で自然に広まった。

さらに重要なのは、この種のルールが Claude Code だけに限られないことだ。どの AI コーディングツールを使っても、本質的な問題は似ている。モデルは、いつ質問すべきか、いつ単純化すべきか、いつ手を止めるべきか、どうやってタスク完了を判断するかを知る必要がある。

06 普通の開発者への示唆

普通の開発者にとっての示唆はシンプルだ。AI コーディングは、一文の要件をモデルに投げて奇跡を待つものではない。本当に有効なのは、モデルに境界を与えることだ。

要件が不明確なときは、まず仮定を表に出させる。実装が複雑になり始めたら、最小の実用解に戻らせる。コードを変更するときは、タスクの目的だけに集中させる。完了時には、テスト、コマンド、明確なチェックポイントで結果を検証する。

AI がコードを書く能力はすでに高い。それでも、よい協作上の制約は必要だ。短い CLAUDE.md がこれほど注目されたことは、開発者が求めているのはより賢いモデルだけではなく、より信頼できる作業方法でもあることを示している。

簡単にまとめると：

書く前に考え、誤った仮定を減らす。
シンプルさを優先し、過度な設計を避ける。
正確に変更し、変更範囲を制御する。
検証可能な成功基準で、目標に向かって進める。

この四つは複雑ではないが、実用的だ。AI コーディングが本当に効率を上げる前提は、モデルにより多く書かせることではない。より正確に、より少なく、より制御された形で書かせることだ。