コードを書かなくても、AIエージェントは使える。でも「エンジニアリング」は消えない

コードを書けなくても、AIエージェントは使えます。

ChatGPTやClaudeに文章を要約してもらい、企画案やメールの下書きを作る。Excelの関数を考えてもらうこともできます。こうした使い方なら、PythonやJavaScriptを先に学ぶ必要はありません。

最近は、作りたいものを自然言語で説明すれば、AIコーディングエージェントがコードを書き、ファイルを変更し、テストまで進めてくれます。僕自身も2021年からプログラミングを学び、個人開発を続けてきましたが、AIコーディングエージェントを使うようになってから、自分の手でコードを書く量はかなり減りました。

この1年間に取り組んだプロジェクトは、数えてみると92件ありました。成果を誇れる数字というより、AIによって開発コストが下がり、新しいプロジェクトへ次々と手を出してしまった結果です。以前の記事でも、AI時代のシャイニーオブジェクト症候群として振り返りました。

コードを書く量が減った一方で、何を作るのか、どのデータを使うのか、どこまで変更してよいのか、正しく完成したとどう確認するのかを考える時間は増えています。

コードをAIに書いてもらうようになって、ようやく分かったことがあります。

コードを書く仕事と、システムを設計して責任を持つ仕事は、同じではない。

AIエージェントを使うだけなら、プログラミングは必須ではありません。でも、本番の業務を任せるなら、仕様、データ、権限、検証、ログ、復旧といった設計は必要です。

利用者本人がすべての責任を持つ必要はありません。本人が持たないなら、プラットフォーム、社内エンジニア、外部の専門家のいずれかが引き受けます。

そこで、コードを書くことと本番運用の責任を分け、非エンジニアが何を学び、どこから専門家へ任せればよいかを整理します。最後には、一つの業務から始めるためのテンプレートも用意しました。

「プログラミングは必要か」には、三つの問いが混ざっている

「AIエージェントにプログラミングは必要か」という問いには、少なくとも三つの意味が含まれています。

1. コードを自分の手で書く必要があるか
2. コードやシステムの仕組みを理解する必要があるか
3. 失敗したときに、原因を判断して直す必要があるか

今後、自分の手でコードを書く必要は、さらに減っていくと思います。構文を覚え、ライブラリを調べ、定型的な処理を一行ずつ書く仕事は、AIが得意とする領域です。

一方、二つ目と三つ目は、本番運用へ近づくほど重要になります。

生成されたコードが読めず、何を変更したのかも、正常に動いているかも確認できない。そんな状態でも、試作品を作るところまでは進めます。

でも、顧客データを扱う、外部サービスを書き換える、毎週自動で動かす、といった仕事では、問題が起きたまま放置できません。誰かが仕組みを理解し、失敗時の判断を引き受ける必要があります。

全員がプログラマーになる必要はありません。ただし、システムの中からエンジニアリングの責任が消えるわけでもありません。

コードを書くことと、エンジニアリングすることは違う

プログラミングとエンジニアリングは、よく一緒に扱われます。実際には、コードを書くことはシステムを作る工程の一部です。

AIは、右側で決めた内容をもとに、左側を実装できます。ところが右側が曖昧だと、AIは不足している条件を推測します。

たとえば「顧客情報を整理して」と頼んでも、対象となる顧客、重複とみなす条件、上書きや削除の可否までは決まりません。コードを生成できることと、正しいシステムを作れることは別です。

実装を代行してもらえても、何を正しい実装と呼ぶのかは、人間側の仕事として残ります。

AIへ渡す権限が増えるほど、必要な設計も増える

AIの利用をすべて「AIエージェント」と呼ぶと、必要な知識の違いが見えにくくなります。この記事では、実務上の整理として、AIアシスタント、AIワークフロー、本番エージェントの三段階に分けます。

OpenAIの実践ガイドも、エージェントを単に回答を生成するモデルとは定義していません。モデルがワークフローを進め、外部ツールを選んで行動するシステムだと説明しています。必要に応じて動作を止め、人間へ制御を戻す仕組みも含まれます。

つまり、AIが賢くなるほど一律に設計が増えるわけではありません。

AIへ渡す権限と責任が増えるほど、必要な設計が増える。

文章の下書きなら、問題が起きても捨てて作り直せます。顧客へメールを送る、商品情報を公開する、データベースを書き換えるといった操作は、簡単には元に戻せません。

同じAIを使っていても、任せる範囲によって必要な知識は変わります。

単発の作業と、業務として運用することは別の仕事

違いが分かりやすいのは、コンテンツ制作とExcelによるデータ分析です。どちらも、単発で手伝ってもらう段階ではコードがなくても使えます。業務全体を任せると、見えなかった設計が表に出てきます。

「記事を書かせる」と「AI編集部を運用する」の違い

AIに記事を書かせるだけなら、テーマと参考資料を渡し、生成された文章を人間が確認すれば終わります。出力がおかしければ、修正するか、作り直せば済みます。

企画から公開までを担う「AI編集部」になると、仕事は次のように広がります。

テーマ候補を集める
→ 優先順位を決める
→ 原典を取得する
→ 構成と本文を作る
→ 事実と引用を確認する
→ 編集ルールで検査する
→ CMSへ下書き保存する
→ 人間の承認後に公開する
→ 公開結果と数値を次回へ引き継ぐ

AI編集部を運用するには、信頼する情報源や古い情報の除外方法、引用URLの確認方法を決めなければなりません。さらに、CMSのどこまで変更してよいか、二重投稿をどう防ぐか、公開に失敗したらどこから再開するかも決める必要があります。

ここで扱う対象は、制作業務全体のシステム設計です。

HF.Mでは、AIを実務で動かすための設計を、プロンプト、コンテキスト、ハーネス、ループという四つに分けています。業界標準として定まった分類ではありません。問題が起きた場所を見つけるための実務上の整理です。

「Excelで集計する」と「分析業務を運用する」の違い

AIにExcelファイルを渡し、「商品別の売上を集計して」「前月と比較して」と頼むだけなら、それほど複雑ではありません。関数や、項目別に集計するピボットテーブルを作り、グラフにするところまで進められます。

毎月の売上レポートを自動で作り、経営会議やクライアントへ提出する業務になると、次の条件が加わります。

• 今月の正しいファイルはどれか
• 「売上」は受注日、出荷日、請求日、入金日のどれで集計するのか
• 税込と税抜、円と千円が混ざっていないか
• 返品、取消、値引きをどう扱うのか
• 商品コードや顧客名の表記揺れをどう扱うのか
• 元データの合計と集計結果が一致しているか
• 誰が数字を確認し、承認するのか

AIは、条件に合う数値を集計するSUMIFS関数やピボットテーブルを作れます。でも、どの時点の数字を経営判断に使うかは、会社の業務ルールや会計方針を知らなければ決められません。

さらに危険なのは、処理が止まることより、一部のデータを除外したまま集計が終わることです。見た目の整ったグラフができても、元データの一部が欠けているかもしれません。

また、分析コメントでは、確認できた事実と考えられる要因を分けます。

確認できた事実：
商品Aの売上は前月比20%減少した

考えられる要因：
販売数量の減少、在庫不足、キャンペーン終了など

追加で確認するデータ：
在庫数、販売チャネル別件数、広告出稿、値引き履歴

AIにExcelを操作させることと、数字に責任を持てる分析業務を作ることは違います。自動化する前に、人間が正しく作った過去のレポートを基準にします。そのうえで、正常な月、欠損のある月、返品が多い月などでも再現できるかを確認します。

本番になると、七つの責任が増える

記事制作でもデータ分析でも、一回の作業を頼むことと、業務全体を任せることの間には差があります。この記事では、本番で最低限考えたい責任を次の七つに整理します。

1. 仕事の仕様

最初に完成条件を決めます。そのあとで、AIへ任せる作業を切り出します。

「競合を調べる」だけでは、対象企業、調査期間、比較項目、必要な根拠、納品形式が決まりません。「月次売上を分析する」だけでも、売上の定義、比較対象、除外条件、提出先は分からないままです。

2. 判断に使うデータ

読む情報を増やせば、回答がよくなるとは限りません。古い資料、重複した資料、出典不明の情報を一緒に渡すと、AIはどれを優先すべきか分からなくなります。

何を保存し、いつ取得し、どの情報を優先するかを決めます。

3. ツールと外部連携

正しい手順を説明できても、実行する手段がなければ仕事は終わりません。ファイル、ブラウザ、メール、CMS、Excel、データベースなど、使えるツールとその結果の扱いを決めます。

4. 権限

読む権限と変更する権限は分けます。下書きの作成と公開、レポートの作成と配信も別の操作です。

権限が広いほど便利ですが、事故の影響範囲も広がります。最初は読み取り専用にし、必要な変更だけ個別に許可する方が安全です。

5. 評価

「完了しました」という返答は、完了の証拠になりません。

確認するのは、必要なファイルや項目の有無、引用URLの実在、元データとの一致、テスト結果、外部サービスへの反映です。AIの自己申告とは別の方法で確かめます。

6. 状態と再実行

途中で止まったとき、最初からやり直すのか、途中から再開するのかを決めます。同じメールが二重送信されたり、同じデータが二重登録されたりしない設計も必要です。

一度動くことと、繰り返し動かせることの間には、大きな差があります。

7. ログと復旧

何を読み、どのツールを使い、何を変更したのか。どの元データと計算式でレポートを作ったのか。記録がなければ、問題が起きても原因を追えません。

何を記録し、誰へ通知し、どこまで元に戻せるか。成功した操作の記録に加え、失敗後の通知や復旧の流れも作っておきます。

ノーコードは、エンジニアリングの置き場所を変える

ノーコードツールや、運用まで提供者へ任せられるマネージドサービスを使えば、API連携やデータベースを自分で実装しなくても、AIワークフローを作れます。すべての会社が認証やログの仕組みを一から開発する必要はありません。

ただ、ノーコードによってエンジニアリングが消えたわけではありません。APIとの接続、認証情報の保存、失敗時の再実行、ログ、データ保管、アクセス制御、監視をプラットフォーム側が引き受けています。

決済を決済代行会社に、サーバーをクラウド事業者に任せるように、専門的な機能を外部へ任せるのは合理的です。

確認したいのは、何を任せているかです。どこまで保証されるのか、どのデータが保存されるのか、誰がアクセスできるのか、サービス終了時に移行できるのか、障害時に誰が復旧するのか。

ノーコードだから安全なのではありません。プラットフォームが用意した範囲で、安全性や運用を代行してもらっていると考える方が実態に近いと思います。

差が出るのは、うまく動いた日ではなく、壊れた日

正常なデータを渡し、想定どおりの質問をして、AIが正しい回答を返した。正常時だけを比べると、エンジニアリング知識がある人とない人の差は小さく見えます。

差が出るのは、想定外の入力が来たときです。

• 必須データが欠けている
• 外部サービスが停止している
• APIの仕様が変わった
• 古い資料と新しい資料が混ざっている
• Excelの列名や数式の参照範囲が変わった
• AIが存在しない情報を作った
• 同じ処理が二度実行された
• 外部データに、AIへの不正な命令が含まれていた

AIエージェントは、メールやウェブサイト、文書、コードなど、外部から得た情報を読んで行動します。そこへ悪意ある指示を混ぜ、予定外の操作をさせる攻撃があります。「間接プロンプトインジェクション」や「エージェントハイジャック」と呼ばれる脅威です。

2026年3月、NIST（米国立標準技術研究所）は大規模なレッドチームの結果を公表しました。レッドチームとは、攻撃者の視点でAIの弱点を探る検証です。13の最先端モデルに25万件を超える攻撃を試したところ、すべてのモデルで少なくとも一つの攻撃が成功しました。

一般業務での事故率とは別の数字です。それでも、モデルの性能だけでは権限設計や監視を省けないことは分かります。

プロンプトに「危険な操作をしないで」と書くことは必要です。でも、それだけでは足りません。危険な操作を実行できない権限にし、高リスクな操作では人間の承認を求め、記録を残します。異常を検知したら停止できるようにするなど、モデルの外側にも対策が必要です。

縮むのは操作の差、広がるのは設計と運用の差

AIによって、エンジニアと非エンジニアのすべての差が広がるわけではありません。入口の差は、むしろ縮むと思います。

AIによってコード生成が一般化すれば、「何かを作れる」というだけでは差別化しにくくなります。Excelの関数やグラフを作れることも、それだけでは大きな差にならないかもしれません。

僕自身、AIを使って92件のプロジェクトへ取り組みましたが、作れるようになっても、それが顧客理解や売上へ自動的につながることはありませんでした。作るコストが下がったことで、売れない現実と向き合わず、次の開発へ逃げやすくなった面もあります。

技術力は成果を増幅します。同時に、間違った方向へ進む速度も増幅します。

何を作り、どの数字を意思決定に使い、どこまでAIへ任せ、何を価値と呼ぶか。こうした判断をシステムへ落とし込めるかどうかが、次の差になります。

非エンジニアは、コードより先に仕事の構造を学ぶ

では、非エンジニアはPythonを最初から勉強した方がよいのでしょうか。

Pythonを学ぶこと自体は無駄ではありません。コードを読めるだけでも、AIが提案した処理を理解しやすくなり、簡単な修正やデータ処理を自分で試せます。

ただ、AIエージェントを使いたい人が、最初にプログラミング教材を一冊終える必要はありません。先に学びたいのは、自分の仕事をシステムとして説明するための知識です。

監督する側の理解も残さなければなりません。

Anthropicが2026年1月に公表した実験には、主にジュニアのソフトウェア開発者52人が参加し、新しいPythonライブラリを学びました。参加者は、コーディング中にAIアシスタントを使うグループと、手作業のグループに分けられています。作業後の理解度テストは、AI利用グループが平均50%、手作業グループが67%で、特に差が大きかったのはデバッグ問題でした。

ただし、これは少人数を対象にした短期実験です。AIを使えば全員のスキルが下がる、という意味ではありません。高得点者には、概念を質問したり、生成後に理解を確かめたりする使い方が多く見られましたが、使い方と理解度の因果関係までは示されていません。

完成物だけを受け取り、理解をすべて手放す使い方には注意が必要です。

必要になったコードは、AIと一緒に学べます。完成物を頼むときも、「なぜこの処理が必要か」「どんな入力で壊れるか」「どのテストが正しさの根拠になるか」まで質問します。

AIを実装と学習の両方に使えば、手で書く量を減らしながら、監督に必要な理解を残せます。

責任は、自分、プラットフォーム、専門家へ分けてよい

ノーコードやマネージドサービスに任せた部分も、最終的には誰かが責任を持っています。では、残った責任を誰へ分ければよいのでしょうか。

すべてを自分で持つ必要はありません。どこまで自分で判断し、どこから先を外部へ任せるかを決めます。

たとえば「請求書を処理したい」という目的と、経理上の承認ルールは利用者が最もよく知っています。認証や実行基盤は既存サービスへ任せられます。顧客データを複数のシステムに書き込む設計や、障害時の復旧は専門家を入れた方が安全です。

本番業務を任せる前に、次の項目を確認します。

• AIが使う入力データを特定できる
• 完了条件を一文で説明できる
• 変更してよい範囲と、読み取り専用の範囲を分けている
• 公開、送信、削除、決済など、承認が必要な操作を決めている
• 正常な結果と異常な結果を比較できる
• 同じ処理を二回実行しても、二重登録や二重送信が起きない
• 失敗した操作を追えるログがある
• 途中から再開する方法か、元に戻す方法がある
• APIやモデルが変わったときの担当者が決まっている
• 一回あたりの費用と、実行回数の上限を決めている

答えられない項目があっても、AIを使ってはいけないわけではありません。ただし、その項目で判断を誤ったときの影響が大きいなら、最初は人間の確認を残すか、プラットフォームや専門家へ任せる必要があります。

よくある質問

AIエージェントを使うには、Pythonを学ぶ必要がありますか

要約、企画、下書き、単発のファイル処理など、多くの用途では必須ではありません。外部サービスとの連携や自動実行へ進むほど、コードを読める人、または設計を補完する人が必要になります。

Excelのデータ分析もAIに任せられますか

集計、グラフ作成、比較、コメント作成は任せられます。ただし、売上や顧客の定義、除外条件、欠損、重複、単位、元データとの一致は人間側で決め、検査できるようにします。

非エンジニアでもAIエージェントを作れますか

作れます。最初は読み取り、下書き、集計など、失敗しても戻しやすい仕事から始めるのがおすすめです。公開、送信、削除、決済は、承認や権限管理を追加してから任せます。

ノーコードツールだけで本番運用できますか

ツールが必要な認証、ログ、再実行、アクセス制御を備え、業務の要件に合っていれば可能です。ノーコードかどうかより、どこまで保証され、失敗時に誰が復旧するかを確認します。

AIの性能が上がれば、テストや監視は不要になりますか

不要にはなりません。モデルの誤りは減っても、入力データの欠損、APIの変更、権限設定、二重実行、外部からの攻撃といった問題は残ります。

どの段階でエンジニアや専門家へ相談すべきですか

顧客・個人データを扱うときや、外部サービスへの書き込み、公開・送信を自動化するときは、設計段階で専門家へ相談する価値があります。停止時の損失が大きい場合や、復旧方法が分からない場合も同様です。

まず、仕組みにしたい業務を一つだけ書き出す

AIエージェントを使うために、Pythonの教科書から始める必要はありません。

まずは、毎週・毎月のように繰り返している仕事を一つ選びます。そして、次の形で書き出します。

仕事：

入力：

処理：

出力：

正常：

異常：

例外：

完了条件：

人間が確認する操作：

失敗したときの対応：

最初から完全自動化を目指さず、入力を限定し、AIに下書きや集計を作らせ、人間が確認します。正解と比較できるようになったら、少しずつ権限と自動化の範囲を広げます。

コードを書く仕事は、これからさらにAIへ移っていくと思います。それでも、何を作り、何を正しいとし、どこまで任せ、壊れたときにどう戻すかという判断は残ります。

その責任は、利用者が持っても、プラットフォームや専門家に任せても構いません。形は変わっても、責任まで消えるわけではありません。

AI時代に学ぶべきなのは、構文だけではありません。自分の仕事を、他者が実行し、検証し、直せる形で説明する力です。

情報元

• OpenAI「A practical guide to building agents」
• NIST「Insights into AI Agent Security from a Large-Scale Red-Teaming Competition」
• Anthropic「How AI assistance impacts the formation of coding skills」
• HF.M「AIエージェントを動かす4つの設計。プロンプト、コンテキスト、ハーネス、ループの違い」
• HF.M「開発コストが下がるほど、個人開発は迷走した——AI時代のシャイニーオブジェクト症候群」

更新履歴

• 2026年7月19日：初版