事例
AIチームで自社サイトを開発・運営
- 区分
- 自社での実践
- 業務
- 何から始めればよいか（AI導入の入口）
hirostaが自社サイトの開発・運営をAIチームに任せている実践です。人が目的と優先順位、公開の範囲を決め、AIが調査・文章やコードの変更・確認を分担します。進んだ件数だけでなく、作業が止まった原因と直し方、任せるための条件を紹介します。
導入前の課題・業務フロー
サイトの会社説明、記事・事例・ガイド、関連リンクや共通部品を継続的に整えるにあたり、AIに任せる作業と人が決めることを分ける必要がありました。変更案ができたこと、確認が通ったこと、公開を承認したことを区別し、目的や確認結果を後からたどれる形に残すことも課題でした。
実施内容
hirostaの社内の開発基盤で、依頼の目的・変更範囲・完了条件を記録し、AIが合意した範囲の調査と変更、ビルドや画面の確認を進めるようにしました。作業するAIと確認するAIの役割を分け、指摘があれば修正します。人は優先順位と承認範囲を決め、変更案と確認結果を見て公開を判断します。
現在の役割分担
- 司令部：優先順位の整理と各部門への割り振り
- マーケティング：サイト分析・情報収集・計測
- コンテンツ制作：記事・事例・業務別ページの作成と補強
- デザイン・開発：見た目・共通部品・サイトの基盤の整備
- 品質管理：定期点検と改善提案
導入後の仕組み・業務フロー
工程 1
- 人
人が目的・優先順位・任せる範囲を決める
人が確認する点新しい実績・数値の公開や、外部への送信などは人が判断します。
工程 2
- AI
AIが依頼を整理し、承認された作業を進める
人が確認する点着手は人のラベル承認、または事前に合意した範囲の代理承認を受けて進めます。
工程 3
- AI
AIが文章・表示・リンクを確認し、指摘を修正する
人が確認する点変更内容と確認結果、未確認の点を残します。
工程 4
- 人
- 通常の自動化
合意した承認範囲に従って公開する
人が確認する点取り込みの承認は本番公開の承認を兼ねます。事前に人が認めた定期作業だけはレビュー合格で自動公開します。
工程 5
- AI
確認結果や止まった原因を記録し、次の改善へつなぐ
人が確認する点修正したことと、止まった作業の復旧を確認したことを区別します。
導入後の変化・成果
公開記事の集計では、2026年9月29日0時〜10月8日12時44分58秒（日本時間）に作成した課題（Issue、PRを除く）が117件、取り込んだ変更案（PR、期間前の作成分も含む）が144件でした。2026年10月8日取得の開発管理履歴による件数で、時間・費用の削減効果を示すものではありません。
成果の確認条件・根拠：対象は自社サイトの開発管理履歴。期間は2026年9月29日0時から10月8日12時44分58秒まで（日本時間）、取得日は2026年10月8日です。公開記事「AIチームでサイトを運営した記録」の集計を再掲しています。課題は期間内の作成数で変更案を除外、変更案は期間内の取り込み数で作成日が期間前のものも含みます。両者は異なる単位であり、記事の本数や作業時間ではありません。部門分担は期間の最終日に始まったため、この件数を現行体制の成果とは扱いません。品質向上、時間・費用の削減、検索や相談への効果も、この集計では確認できません。
使っている仕組み
hirostaの社内の開発基盤。AIによる調査・変更・確認と、承認後の公開処理を組み合わせています。
AIと人の役割
AIに任せた範囲
調査、文章・コードの変更案、ビルドと画面の確認、レビュー指摘への修正を担当します。2026年10月11日時点では、記事の追加・内容の補強・業務別ページの改善などを定期作業で進めています。司令部は毎日8時から17時まで毎時、事前に人が認めた範囲で次の作業を補充します。この時間帯は運用の設定であり、実際に動いた回数の集計ではありません。
人が確認するポイント
人が目的・優先順位・実績として公開できる根拠・着手と公開の承認範囲を決めます。原則は着手と本番公開を別々にラベルで承認します。例外として、事前に人が認めた記事の追加・内容の補強・業務別ページや事例の改善は、レビュー合格で自動公開します。この事例の追加は、人が内容を確認して公開を承認する対象です。
導入時に苦労した点
- 2026年10月8日、運用手順のファイルを別のファイルへの参照リンクに変えたところ、自動作業の安全確認が止まり、調査が開始直後に停止しました。ファイルの扱いと安全確認の条件が合わなかったことが原因です。
- 安全確認は外さず、参照リンクを通常のファイルに置き換えました。同じ手順を複数箇所で使う場合は、同じ変更で内容を揃えるルールも運用資料に残しました。公開記事では同日の修正の取り込みを確認していますが、止まった調査がその後完了したかは未確認です。
導入後に分かったこと
- ページの見た目を変えない運用ファイルの変更でも、自動作業を止めることがありました。そのファイルを読む側の制約も確認対象にする必要があります。
- 原因に対応した修正が取り込まれたことだけでは、運用が復旧したとは言えません。原因・修正・復旧確認を分けて記録することが大切です。
- 部門ごとの役割を決めても、件数だけでは品質や効果を評価できません。何を変更し、どこまで確認できたかを残して、次に任せる範囲を判断します。
同様の取り組みが向いている条件
- 記事や共通部品の改善など、変更を小さな単位に分け、目的・範囲・完了条件を記録できるサイト運営。
- AIの変更案をそのまま公開せず、文章・表示・リンクの確認と、人が承認する範囲を決められる体制。
- 作業が止まったときに、原因と直し方、未確認の点を残し、運用手順も見直せる取り組み。
補足
自社サイトでの実践から整理した条件です。お客様への導入実績や、同じ件数・所要時間になることを保証する事例ではありません。件数と停止例は公開記事の対象期間、役割と定期作業は2026年10月11日時点の運用を説明しています。