非エンジニアがAI開発で機能を出した社内で、エンジニアに残った2つの行為

非エンジニアのAI開発を社内で開くかどうかを決める前に見るべきは、投資の優先順位で低いと評価された企画が、エンジニアの時間を使わずに本番へ出る経路が既に自分の組織にあるかどうかである。本稿が調べた範囲では、この話題で検索上位に出るのは、内製化を支援するサービスの紹介、非エンジニア向けのAI開発研修の事例、市民開発の解説、統制製品のページだった。顧客に出る機能を非エンジニアが通した記録と、そのときエンジニアに何が残ったのかを書いたものは見つからない。本稿はその一点に絞る。

非エンジニアはどこまで本番の機能を出せるようになったのか

具体的な場面から入る。30人のメディア企業Everyは2026年6月、有料記事を非会員に共有できるギフトリンク機能をソフトローンチした。7月17日の告知時点で、標準の有料会員は月5本、All Access会員は無制限に共有できる。機能そのものは新しくない。Wall Street JournalやThe Atlantic、New York Timesのオンライン版で誰もが目にしている。ただしそれらの媒体は、Every全社より大きいプロダクトチームを持つ、と元記事は書いている。

この機能を実装したのは、開発者ではなく上級編集者のJack Chengである。Codexと当時のフロンティアモデルを使い、空き時間の案件として通した（非エンジニアはAIでどこまで機能開発できるか——編集者が空き時間でギフトリンク機能をリリースした実例）。

彼が自分の行為として書いているのは、実装だけではない。まずEveryのSlackとDiscordを検索して、過去に同じ案が出ていないか、提案されて却下されていないかを調べた。そこで編集長Kate Leeが同じことを考えていたメッセージが出てきた。次にSlackの自前のエージェントとChatGPTで深掘り調査を2本走らせ、2つの報告を比較し、引用元——多くはNieman Journalism Labの研究——を検証し、理解を確かめるために追加の質問をした。そのうえで事業上の根拠と実装計画を含む報告書を作った。バックエンドのどこを変える必要があるかは、Codexを既存のコードベースに向けて特定している。

できるようになった理由として元記事が挙げているのは、まず能力の変化である。 今日のフロンティアモデルと、Claude・Codex・Cursorのようなエージェント統括アプリの能力が、これを空き時間の案件として成り立たせた——という書き方だ。能力そのものが上がったという書き方である。ただし同記事は、能力と並べて組織側の条件も述べている（後述）。

同時に、これが広く起きている形なのかは分けて見る必要がある。同じ会社の別の記録に、コンピュータ操作機能（エージェントがアプリをクリックし、文字を打ち、スクロールして直接動かす機能）に社員が何を委任しているかの一覧がある。挙がっているのは7人で、動画・事業開発・ソーシャルメディア・コンサルティング・運営の各責任者とCEO、そしてエンジニア1人である。並べると様相が違う。事業開発を率いるBrian Dellはカレンダーの維持を任せており、本人はこれを、成人してから自分がやったなかで最もレバレッジが効いたことだと評している。コンサルティング責任者のNatalia QuinteroはVerizonのより良いプランの比較を任せ、サポートチャットに直接入力させて担当者の返答を読ませ、自分は別のことをしていた。CEOのDan Shipperは新居へのインターネット回線の移転を任せている（Every、Laura Entis、2026-09-15。AIエージェントの画面操作（computer use）で任せられる定型作業の範囲）。

7人のうちエンジニアを除く6人が非エンジニアである。その委任先は3通りに散っている。本人の私生活の段取り。外部の窓口への手続き——古い修理依頼を探して追加の問い合わせを出す、通信プランを比較して問い合わせる、フリマへ出品する、回線を移転する。そして社内の業務——Slackで添付つきの返信を出す、Figmaから書き出した画像をSNSの予約投稿ツールの投稿に添える、自分のAI利用状況のレポートを作らせる。外部や仕事に触れないわけではない。ただし、原文から読み取れる範囲では、自分の会社の製品やサービスの面を変える作業は含まれていない。 元記事自身が、これらは特に難しい作業ではなく、人が後回しにしがちなほどには面倒な作業だと書いている。今回読んだ2件の記録の範囲では、非エンジニアの委任は製品の面の外に集まっており、顧客に出る機能まで通した記録は、同じ会社でもギフトリンクの1件である。なお、コンテンツ制作の工程をエージェントに寄せた構成としては、150万人超のフォロワーを持つAIクリエイターRiley Brownの事例が対談の告知で紹介されている（告知文のみに基づくため、本稿では論点の紹介にとどめる。Behind the Craft、Peter Yang、2026-08-16。コンテンツ制作チームは何人必要か ― Codex で150万フォロワー事業を回す AI ツールスタック）。

そのときエンジニアに残った責任は何だったのか

ギフトリンクの記録で、ウェブのエンジニアリードAndrey Galkoの関与として元記事が書いているのは、2つである。

1つめは指摘だ。Chengは参考にしたニュースサイトのUIフローのスクリーンショットを報告書に足してGalkoに共有し、アーキテクチャについての意見を求めた。返ってきたのは、コードベースで記事プレビューをどう扱っているか確認せよ、という指示だった。2つめはレビューである。Chengがドラフトのプルリクエストを出し、Galkoは自分のCodexにそれをレビューさせた。

レビューは名目上エンジニアに残ったが、実作業はエンジニア自身のエージェントに渡っている。 したがって、この記録から「エンジニアがプルリクエストを読む役として残った」とは読めない。一方で、この2つが関与の全部だったとも元記事は書いていない。計測ページの設置、ステージングへのデプロイ、社内テスト、ソフトローンチを書いた各文の主語は「We」であり、誰が手を動かしたかは書かれていない。言えるのは、元記事が書いているGalkoの関与は2つであり、同記事が「彼の関与をさほど必要とせず」と性格づけているところまでである。

1つめの指摘が何を指していたかには、突き合わせると見える解釈の余地がある。Chengが過去の議論を検索したとき、Everyのシステムには記事ごとにペイウォールを回避するプレビューリンクが既にあり、ただしそれは社内でドラフトを共有する用途寄りに作られたものだった、と元記事は書いている。新機能はまさに、ペイウォールの回避を社外へ開くものである。エンジニアが指した1点は、既存の仕組みの前提——社内限りという前提——が変わる地点だった、というのが本稿の読みである。元記事はこの因果を書いていない。書かれているのは、確認せよという指示と、プレビューリンクが社内用途向けだったという事実の2つが別々にあることまでで、指示の「記事プレビュー」がこのリンクを指すのかどうかも同記事は説明していない。本稿はこの読みの上に以降の議論を組むので、ここが外れれば以降も外れる。

スコープの判断を誰が下したかも、正確に見ておく価値がある。元記事の書き方は、これはGalkoの関与をさほど必要とせずに自分で現実的にやれる、明確にスコープの切れたプロダクト変更だということは、Galkoを含め全員にとって明らかだった、というものだ。エンジニアが判定したのではなく、全員にとって明らかだったと書かれている。 スコープの線が自明だったケースであり、自明でない変更で誰が線を引くかは、この記録の外にある。

関連して、非エンジニアの側が設計の技能をどう扱っているかの記述もある。コンサルティング責任者のNatalia Quinteroは、Claude Codeではフォルダ構成とファイル体系を作るのに多くの時間を割いていたが、Codexではアプリが作業しながら組んでくれるため同じような作り込みが要らなくなった、という文脈でこう述べている。

“I have to focus a little less on architecting things well—which is very much a skill and something our engineers do extremely well. I can just trust it to make good decisions and build solutions for me.”

（きちんと設計することに向ける意識は少し減らしてよくなった——それはまさに技能であり、うちのエンジニアが非常に得意とすることだ。良い判断をして自分のために解決策を作ってくれると、ただ信頼していればいい。出典: Every by Laura Entis、2026-07-02）

ここで言う設計は、彼女自身の作業環境の構成を指しており、製品のアーキテクチャの話ではない。彼女が実際に通した仕事も、コンサルティングチームが使うCRMの整備である。受信トレイ・会議の書き起こし・パイプラインのロジックにアクセスできたため、彼女が寝ている間に数百件の顧客・見込み客のレコードが拡充された。何週間もかかっていた仕事だった、と彼女は言う（Codexの実践的な使い方はどう設計するか ― 長期スレッド・コンテキストフォルダなど4つの運用パターン）。顧客に出る機能ではない。それでも、設計がエンジニアの技能だと認めたうえで、自分はそこへの意識を減らしてよくなったと言える人が、非エンジニアの側に既にいるという点は記録しておく価値がある。同じ言い方が製品の面の変更にも持ち込まれたときに何が起きるかは、彼女の発言の外にあり、本稿の問いである。

どこに統制の線を引くか

線は許可の有無では引けない。企画を通した場で、優先順位の評価と着手の許可が分かれているからだ。

Chengは成長責任者Austin Tedescoに打診した。最初の反応は「interesting」で、Tedesco本人が後の対談で、あれは「時間を無駄にさせるな」と伝える言い方だったと語っている。ただしnoでもなかった、と著者は書く。著者は理由も書いている。アイデアをTedescoや他の関係者に売り込み、Galkoをより急ぎの案件から引き離す価値があると組織に納得させるために必要な追加の時間と労力は、見返りに見合わなかっただろう、と。

実装計画を含む報告書を見たあとのTedescoの返答は、報告書を見る限りギフトリンクは成長の優先事項には見えない、ただしCodexで自分でやりたいならどうぞ、というものだった。Tedescoは後に、以前の自分はリソースを守りに回る働き方をしていたが、思い切ってやってみるのが一番いいと腹を決める瞬間があった、ユーザーの行動の流れとデータで実際どうなるかを見るほうがずっといい、と語っている。つまり評価が低いまま据え置かれたのではなく、評価の基準そのものが動いている。

却下されたのではない。返答の時点では成長の優先事項として低く評価され、同じ返答のなかで着手の許可だけが出ている。 ここでいう青信号は、Tedescoの返答だけで成り立っているわけではない。元記事は、これはGalkoの関与をさほど必要とせずにやれる明確にスコープの切れた変更だということがGalkoを含め全員にとって明らかだった、と書いたうえで、欲しかった青信号が出たと続けている。そして本番に出るまでには段階がある。同記事は、ドラフトのプルリクエストのレビューのあとステージングサーバーにデプロイし、編集長と成長責任者のフィードバックを受け、社内で試してからソフトローンチしたと書いている。この返答で開いたのは着手であって、出荷ではない。

Chengはこう書く——他のたいていの会社なら、いや1年前のEveryであっても、自分はそこで止めていたかもしれない。これを一般化すると、次の整理になる（ここからは本稿の整理である）。従来、優先順位づけで低いと評価された案は実装されなかった。実装にエンジニアの時間が必要で、その時間の配分が優先順位づけそのものだったからだ。自力実装の経路が開くと、この2つが分離する。優先順位づけは「投資するか」の判断に縮み、「着手するか」を決めなくなる。 自分の組織でこの経路が既にあるなら——コーディングエージェントが配られ、ステージング環境に触れる人が開発職の外にいるなら——許可を議論している間にも変更は出ている。

では何を決めるか。元記事に、組織の設計条件そのものを述べた文がある。

“If an organization is set up to support what AI tools make possible, non-technical teams can dream up, validate, build, and launch an idea—all without diverting resources from higher-stakes work.”

（AIツールが可能にすることを支えられる組織設計になっていれば、非技術チームはアイデアの発想から検証・開発・リリースまでを——より重要度の高い仕事からリソースを割くことなく——やり遂げられる。出典: On Every (every.to) by Jack Cheng、2026-07-17）

この文は条件節である。支えられる設計になっていれば、と書いてあって、その設計が何かは書いていない。ギフトリンクの記録から取り出せる要素は、先の2つの行為しかない。変更の種類ごとに、既存のどの前提に触るかを言う人を名指しすること。それが本稿の読む線である。 権限を誰が動かせるかという、より上流の決め事についてはAIエージェントに社員と同じ権限を渡せるか ― 権限境界設計を経営の意思決定に引き上げるで別に扱っている。本稿が扱うのは、線を動かす所有権ではなく、線の手前で誰が何を指すかである。

名指しの中身を考えるうえで、別の元記事（Every「Codex in Practice」、Laura Entis、2026-07-02）の構成も参考になる。同記事は4人の運用パターンごとに、読者がそのまま使える設定プロンプトを載せている。そのうち3本に、人の確認が必要な範囲を自分で書き出させる項目がある。エージェントが自分の代わりに下書きまで進めてよい行動と明示的な承認を要する行動を分ける項目、共有や出荷の前に自分が確認すべきものを挙げさせる項目、エージェントが単独でやれることと自分が確認すべきことと結果が良いと言える証拠は何かを定める項目である。4本目は承認の項目を持たず、代わりに避けてほしい習慣を書き溜めるルールファイルを置く。これらは読者が自分の運用を始めるための見本として載っているもので、本人たちの実際の運用の記述ではない。 実運用として同記事が地の文で書いているのは、成長責任者が最初の版をレビューし、出力が悪いか複雑すぎれば、どこで間違えたかをエージェント自身に点検させて構成を直させる、という形である。確認は事後に置かれている。

最初に開放する領域をどう選ぶか

手がかりは3つある。以下はいずれも、記録された事例から本稿が組み立てた整理である。

第一に、製品の面を変えない作業から開く。 コンピュータ操作機能に委任されている作業が実際にそうなっている。カレンダーの維持、フリマ出品、通信プランの比較、回線の移転、Slackでの返信、予約投稿ツールへの画像の添付。外部の窓口や社内の業務に触れるものもあるが、製品やサービスの面は変えない。同じ元記事で評価責任者のMike Taylorが自分の広げ方として書いているのも、この順である。最初に任せたのは学校の書類記入1件で、どう振る舞うかを見届けた。それで自信がついて、Google スライドの更新や動画編集といったより踏み込んだ作業へ進んだ。

第二に、既存の仕組みの前提に触らない面から開く。 ギフトリンクは逆の例だったと本稿は読む。ペイウォールという、事業の収益構造そのものに関わる前提に触る変更であり、エンジニアの関与として記録されている指摘も、その周辺を指していたと本稿は読む。自分の組織で非エンジニアに最初に開く面を選ぶなら、認証、課金、データの保持期間、外部への公開範囲といった前提に触らない範囲——たとえば管理画面の表示、社内向けの集計、既存の権限の中で動く画面——を先に取る。どの面がどの前提に触るかを書けないなら、まずその一覧を作るのが先である。

第三に、エージェントが間違う形を事前に見ておく。 マーケティング責任者のDouglas Brundageのスライド作成の工程には、初稿のレビューが明示的に置かれている。Codexは間違える、とある。あるデッキでは1枚のスライドに30個の例を詰め込んだ。ただし間違いは直しやすく、彼は自分で手を入れるかCodexに指示するかを選び、最後に修正内容を規則に変えて保存させている。失敗が起きるかどうかではなく、失敗が見てすぐ分かる形で出るかどうかが開放する面の条件になる、というのが本稿の見立てである。スライドの詰め込みは見れば分かる。認証の回避は見ても分からない。

そして3つを満たしても残るのが、スコープが自明でない変更である。ギフトリンクは全員にとって自明だった。自明でない変更で誰が線を引くかは、名指ししておく以外にない。プロダクトチームの側で誰にリリース権限を渡すかという問いは、AI時代のプロダクト組織を少人数にする前に、誰にリリース権限を渡すかで扱った。本稿の問いはその隣にある。権限を渡した相手が、既存のどの前提に触るかを自分では判断できないときに、誰が指すのか。

まとめ: 開放の可否ではなく、優先順位づけが何を決めなくなったかを見る

非エンジニアのAI開発を社内でどう扱うかという問いは、許可の範囲を決める問いに見えて、実際には優先順位づけの役割が変わったことの問いである。Everyのギフトリンクは、成長の優先事項には見えないという評価を受けた同じ返答のなかで、着手の許可を得ている。優先順位の評価と着手の許可が、そこで分かれている。そのとき元記事が書いているエンジニアの関与は2つで、1つはコードベースの1点を確認せよという指摘、もう1つは自分のエージェントに渡したレビューだった。これは30人の企業の1件の記録であり、同じ会社について今回読んだ記録に挙がっているのは、製品の面を変えない作業の委任のほうである。それでも経営が今期決められることは1つある。リスクの高い変更の種類を2つか3つ選び、それぞれについて「この変更が既存のどの前提に触るか」を言う人を名指しすることだ。その人の仕事は実装の代行でもプルリクエストの読み合わせでもない。触る前提を指すことである。名指しがないまま経路だけが開いている組織では、設計がエンジニアの技能だと認められたまま、その判断を誰も持たない状態になりうる。これは本稿の仮説であり、今回の記録から確かめられた事実ではない。