この記事を書いた人
- 星テクニカルグループ/第2テクニカルチーム（ビジネス・アーキテクツ）
2022年にフロントエンドエンジニアとして働き始め、2026年にビジネス・アーキテクツに入社。現在でもフロントエンドエンジニアとしてリニューアル案件や運用案件を担当している。
「軽微な修正なのに、依頼してから反映まで時間がかかる」「コードが書けない自分には、改修なんて無理」Web運用の現場では、こうした“あたりまえ”が少なくありません。
Business Architects（ビジネス・アーキテクツ、以下BA）でも、社内運用で同じような課題がありました。ディレクターには「すぐ直したいのに進められない」もどかしさがあり、エンジニアにとも、細かな修正対応が積み重なることで本来集中したい開発時間が分断されてしまうという課題です。
そこでBAでは、非エンジニアのディレクターとエンジニアが一緒になって、生成AIとBacklog MCPを活用したWeb改修の自走化に取り組みました。ディレクターが起票からデプロイまでを自分で進め、エンジニアは仕組みづくりやレビューで支える。その実践の流れと、取り組んで見えてきた成果・課題を紹介します。
「ここを直すだけなのに、なぜ進まない？」運用現場のもどかしさ
Web運用の現場では、軽微な修正であっても、エンジニアの工数を確保しなければ進められないことがよくあります。たとえば、キャンペーン終了にともなうお知らせ文言の差し替え、トップページのバナー画像の変更、遷移先が変わったリンクの修正などです。
BAの社内運用でも、お客さまのWebサイトの運用でも、こうした依頼は日々発生します。作業そのものは小さくても、依頼、スケジュール調整、対応待ちという工程が挟まることで、反映までに時間がかかってしまうのです。
ディレクターからすると、「ここを直すだけなのに、なぜすぐに進められないのか」というもどかしさが生まれます。お客さまに早く修正を返したい。画面を見る限りだとその場で直せそうにも思える。でも、自分はコードを触れない。こうした少しの待ち時間が重なることで、対応スピードが落ちていってしまいます。
そうした課題を、ディレクターとエンジニアの双方で共有する中で、「非エンジニアでも、自分で対応できる改修の範囲を広げられないか」という発想が生まれました。そこから、生成AIとBacklog MCPを活用した社内検証が始まりました。
なぜBAがこの取り組みに踏み出したのか
この課題は、BAに限った話ではありません。いろいろなWebサイトの運用現場でも、軽微な修正が依頼と調整の間で止まったり、行き来したりするうちに、反映までに時間がかかってしまっているケースは多いことでしょう。
とはいえ、お客さまの案件でいきなり試すわけにはいきません。だからこそ、まずは社内案件で先に検証し、どこまでなら非エンジニアが対応できるのか、どこでエンジニアの確認が必要になるのかを確かめることにしました。
Webの制作・開発に携わるBAにとって、ここで得た知見は、社内の効率化だけでなく、お客さまのWeb運用をよりスムーズにする支援に活かせると考えています。
非エンジニアでも改修を回す仕組み。どう実現したか
目指したのは、「課題の起票から実装・デプロイまでを、非エンジニアが自分で回せる状態をつくる」ことです。その手段として、生成AI（Claudeなど）とBacklog MCPを組み合わせました。
Backlog MCPは、AIがBacklogの課題情報や関連するリポジトリ（Webサイトのソースコードを管理している場所）を参照するための接続役です。この接続により、ディレクターが課題の背景や修正対象のファイルを細かく説明しなくても、AIが必要な情報を参照できるようになります。課題のURLを渡し、修正の意図を添えるだけで、AIと修正のやり取りを始めやすくなります。
とはいえ、最初からすべてをAIに任せたわけではありません。まずは小さな依頼から試し、うまくいった範囲を確認しながら、対象を少しずつ広げていきました。実際に取り組んでみると、AIに任せられる範囲は想像以上に広い一方で、最初の環境づくりや運用ルールの整備には一定の準備が必要なことが分かりました。
安全に任せるための線引き。非エンジニアがAIを使う最低限のルール
非エンジニアがAIを使って改修を回すうえで欠かせないのが、「どこまで自分でやってよいか」の線引きです。ツールが使えることと、任せられることは別の問題です。自由度を上げながら事故を防ぐために、最低限のルールを決めました。
線を引くときの基準には、大きく2つの視点があります。ひとつは「影響範囲」です。その修正がそのページの中で完結するのか、共通パーツを通じてサイト全体に波及しうるのか。もうひとつは「戻しやすさ」です。問題が生じたときに画面を見てすぐ気づけるか、すぐ元に戻せるかです。この2つを判断基準として設定しました。
この基準で見ると、テキストや画像の差し替えは影響がページ内で完結しやすく、結果も見た目で確認できるため、ディレクター単独で対応できるものとしました。一方、CSSは共通スタイルを通じてほかのページに波及することがあるため、レビューを必須としました。JSやテンプレート構造は、見た目だけでは問題に気づけない場合があるため、エンジニア対応としました。あわせて、AIが生成したコードを誰が確認し、誰が本番反映を最終承認するのかも定めました。
もちろん、すべての依頼がきれいに線引きできるわけではありません。そこで、迷ったときは無理に進めず、相談に切り替えられる運用にしています。このとき大切なのは、「判断に迷ったこと」自体を責めないことです。相談することのハードルが上がると、せっかく決めた線引きが形骸化してしまうからです。
線引きを1枚にした「ディレクター可動領域マトリクス」
この線引きを現場で判断しやすくするために、「修正対象 × 承認レベル」で整理したのが「ディレクター可動領域マトリクス」です。テキストや画像はディレクター単独で対応できるもの、CSSはペアレビューが必要なもの、JSやテンプレート構造はエンジニアが対応するものとして整理しました。
区分ごとの判断理由は次のとおりです。
- テキスト・画像→ディレクター単独可
影響がページの中で完結し、結果を表示で確認できるテキストや画像は、ディレクター単独で対応できるものとしました。万一間違えても、元のテキストや画像に戻すだけでリカバリーできます。 - CSS→ペアレビュー必須
余白や文字サイズの調整など、一見軽微な変更でも、CSSは共通スタイルを介してほかのページへ波及することがあります。そのため、ペアレビューを必須としています。 - JS・テンプレート構造→エンジニア対応
フォームの動作や表示の出し分けなど、見た目だけでは気づけない変更が含まれるJSやテンプレート構造は、エンジニア対応としています。影響が「画面で見えている範囲」を超えて広がる可能性があるため、AIで直せそうに見えても対象外としました。
このマトリクスを用意したことで、現場の判断が属人的になりにくくなります。大切なのは最初から完璧な線引きを目指さないことです。まずは狭い範囲から始め、実績が積み上がった領域から少しずつ「単独可」を広げていく前提で運用しています。
また、線引きは一度決めたら終わりではなく、運用しながら見直していく前提としています。今回使った「修正対象 × 承認レベル」という整理は、役割分担や確認フローを考えるうえでも有効でした。
なお、AIによる変更も、後から「誰の承認で、何を根拠にしたか」を追えるようにする必要があります。そのため、コミットやレビューの記録ルールもあわせて整備しました。詳細は記事末の【付録コラム】を参照してください。
実案件での1チケットの流れ。ディレクターとエンジニアはどう動いたか
ここからは、実際のチケットを1件取り上げ、起票からデプロイまでの流れを追ってみます。対象は、社内から挙がった「コラムページのH2見出しがPCで小さく、読みづらい」という指摘です。
従来であれば、エンジニアの手が空くタイミングを待って対応する規模の修正です。今回は、ディレクターがAIを使って修正を進め、エンジニアがレビューで支える形を採用しました。
ステップ①課題起票（Backlog）
指摘を受けたディレクターは、まずBacklogに課題を起票します。テンプレートに沿って、修正対象ページのURL、現状のスクリーンショット、「PCではH2見出しをひとまわり大きく。スマホは現状のまま」という修正後の状態、そして公開希望日を記載します。
起票時には、「AI可」「要エンジニア」のラベルも付けます。今回は見出しサイズの調整で、影響範囲の限られたCSSの修正にあたるため「AI可」としています。前章のマトリクスでいえば、「ペアレビュー必須」の区分になります。判断に迷う場合は、無理をせず「要相談」を選ぶように共有しています。
ステップ②AIへの指示出し（生成AI × Backlog MCP）
次に、起票した課題のURLをAIに渡します。AIはMCP経由で、課題本文、添付のスクリーンショット、修正に関するソースコードをリポジトリから自動で参照します。そのため、ディレクターが補足した指示はほぼ一言です。
「H2見出しのフォントサイズを少しだけ大きくしたい。スマホでは変えないで」
これを受けてAIは、見出しのスタイルを定義しているCSSファイルを特定し、PC向けのフォントサイズを一段階大きくする修正差分（diff）を提示します。ここまで、ディレクターはコードを1行も書いていません。
ステップ③差分確認とステージング環境への反映
提示された差分は、CSSファイルのフォントサイズ指定が1行変わっているだけです。スマホ向けの記述には、手が入っていないことも読み取れました。
自分ではコードを書けなくても、変更内容を見て、意図と合っているかを確認することはできます。分からない点が残る場合は、「なぜこの修正をしたのか」「ほかのページに影響はないか」とAIに質問し、確認しながら進めます。
差分に問題がなければ、ブランチ作成、コミット、プルリクエスト（修正内容を確認・承認してもらうための依頼）の作成もMCP経由でAIに依頼します。その後、ステージング環境で実際の見た目を確認しました。記録のルールは、先に定めた線引きに従います。
ステップ④エンジニアの簡易レビュー
「AI可」ラベルのチケットは、エンジニアがプルリクエストを簡易的にレビューします。確認するのは、修正意図と差分が合っているか、ほかのページへの影響がないか、コーディングルールに沿っているかです。
今回はここで、「同じ見出しスタイルを使っている別のページにも変更が及ぶ可能性がある」という指摘が入りました。まさに、CSSを「ペアレビュー必須」とした理由そのものでした。
そこでディレクターは、対象となるページをコラムに限定するようAIに修正を依頼しました。その後、直した差分とステージングの表示を再確認しました。
ステップ⑤本番デプロイと事後確認
レビュー承認後、Backlogのステータス変更をトリガーに、本番へデプロイします。ディレクターは本番ページで見出しの表示を確かめ、依頼元へ完了を報告しました。
このチケットは、起票からその日のうちに本番反映まで完了しました。従来であれば、依頼から数日待つこともあった規模の修正です。
表示が崩れた場合に備え、ロールバックの手順は事前にエンジニアと合意しておいたことを付け加えます。
今回のケースで起きたトラブルと、その対処
実際に運用してみると、想定どおりに進まないこともありました。今回のケースにおけるトラブルと対処をまとめます。
- AIが意図と違うファイルを触ろうとした
修正対象や影響範囲をプロンプトで明示し、対象を限定した - ステージングで表示が崩れてしまった
差分を戻し、「要相談」ラベルに切り替えて、エンジニアと確認しながら進めた - 修正箇所をうまく言語化できなかった
スクリーンショットに矢印を入れて指示する形式で統一した
やってみて得られた成果と課題
実際に運用してみると、うまくいった点だけでなく、つまずいた点も見えてきました。
まず、成果として大きいのはスピードです。先ほどの見出し修正のように、これまでエンジニアの対応を数日待つこともあった軽微な修正が、起票した当日中に本番反映まで進むようになりました。「依頼して待つ」時間が、「AIとやり取りする」時間に置き換わったイメージです。
もうひとつの成果は、ディレクターが自分で対応できる範囲がはっきりしたことです。テキストの差し替えや画像の変更、影響範囲が限られたCSSの調整までは、エンジニアに依頼する前にディレクターが一次対応できるようになりました。
細かな依頼が動き出しやすくなっただけでなく、エンジニアの確認が必要な案件でも、「AIに差分を作らせ、ディレクター側で確認した状態」で相談できるため、共有のやり取り自体が短くなっています。
非エンジニアのディレクターからは、次のような声も上がっています。
「コードを書き換える必要もなく、コマンドの入力とAIとのやり取りだけで作業が完結することが画期的だった」
「マニュアルがあれば、これくらいの作業自体は誰でもできるようになると思う」
一方で、つまずきもありました。AIが意図と違うファイルを触ろうとしたり、ステージングで表示が崩れたり、修正箇所をうまく言語化できなかったりする場面です。
こうした場面では、修正対象や影響範囲をプロンプトで明示する、差分を戻して「要相談」に切り替える、スクリーンショットに矢印を入れて指示するなど、運用しながら対処方法を整理していきました。
うまく回った要因は、線引きとラベル運用、そして迷ったときに「要相談」ラベルへ切り替えられるチーム連携にありました。
非エンジニア担当者のリアルな声
「コードが書けなくても改修できた」という効果は大きい一方で、AIを道具として使いこなすには、要件を言語化する力と、差分を読んで意図が合っているかを判断する力が必要でした。
また、「AIをどこまで信用していいのか分からない」という不安もあります。だからこそ、最後は自分で差分を確認できることが安心につながります。Gitやマークアップの基礎知識が少しあるだけでも、確認の精度は上がります。たとえば、自分がメインブランチにいるのか、切り出したブランチにいるのかが分かるだけでも、事故は起こりにくくなります。
残っている課題として挙がっているのは、「数回、通しで一緒に確認できると安心」という声です。やってはいけないこと、注意すべきところ、やりがちな失敗、ミスしたときのリカバリー方法を整理したマニュアルがあると、より安心して任せられそうです。作業開始前にメインブランチを最新の状態にしておくといった準備の工程も、こうしたマニュアルに含めて標準化していきたいところです。
エンジニア側で得られた知見
レビュアーに回ったことで、運用設計の勘所が見えてきました。たとえば、AIが作成した差分は一見正しそうに見えてしまうため、レビュー時には「修正意図と差分が合っているか」「影響範囲が広がっていないか」「戻せる状態になっているか」を念入りに確認していく必要があります。
また、非エンジニアに任せる範囲を広げるには、レビューだけでなく、作業環境や手順の標準化も欠かせないことも改めて確認できました。軽微な改修をディレクターに任せられるようになったことで、エンジニアはコア開発に集中しやすくなりました。今後は、初期設定を簡易化し、マニュアルを整えることで、任せられる範囲をさらに広げていきたいと考えています。
まとめ。非エンジニアが自走できると、現場はどう変わるか
振り返ってみると、この取り組みの核心は、AIを導入したことそのものではありませんでした。AIに任せる範囲を線引きし、レビューと承認の流れを決め、迷ったときに「要相談」へ切り替えられる相談ルートを用意する。そうした運用設計があったからこそ、非エンジニアでも安全に改修を回せるようになったのだと感じています。
生成AIやBacklog MCPといった道具は、これからも進化し、入れ替わっていくはずです。それでも、「誰が、どこまで、どう確認して任せるか」という設計の考え方は、道具が変わっても使い続けられます。
この取り組みは、社内の効率化だけを目的にしたものではありません。ディレクターとエンジニアが一緒に検証し、運用設計まで含めて整理した知見は、お客さまのWeb運用改善や内製化支援にも活かせるものです。
AIを活用したWeb運用の自走化は、ツールを導入するだけでは定着しません。任せる範囲を決め、レビューと承認の流れを整え、迷ったときに相談できる体制を用意することが欠かせません。BAでは、こうした現場での検証を通じて得た知見をもとに、Webサイトの運用改善や内製化支援にも取り組んでいます。
【付録コラム】AIの変更を"追える"状態にする技術的な工夫（エンジニア向け）
最後に、AIによる変更を後から追える状態にするための技術的な工夫を、エンジニア向けに補足します。読み飛ばしても本文の理解には支障ありません。
- コミット情報の整理
AIが生成したコードのGit author / committerの扱いについて、サービスアカウント、個人トークン、AI専用ボットなどの選択肢を比較し、採用方針とトレードオフを整理します。 - Signed-off-by運用
AI支援であることを示すtrailerの付与、たとえば「Assisted-by:Claude via Backlog MCP」に加え、最終承認者である人間のSigned-off-byを残すことで、責任の所在を明確にします。 - PR説明欄へのプロンプト記録
AIへ渡したプロンプトをPRのdescriptionに残し、差分との対応や、後から確認する際の再現性を担保します。
そのほか、レビュー粒度の決定、ステージングから本番への確認フロー、ロールバックの責任者と手順も、あわせて決めています。