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 ソフトウェア開発は「システムが検証可能に正しい結果を継続して出す」ことをより重視するようになる。

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

Peter Steinberger on KnightLiブログ