結論から：AI開発会社は「おすすめ一覧」で選べません。運用を自社で持つのか、相手に委ねるのかで、適した会社が変わるからです。前者なら引き継ぎやすい構成で作る会社、後者なら稼働の責任範囲を契約に書ける会社で、この2つは別の会社であることが多いです。そして選定で本当に効くのは技術力より「動かし続けた経験があるか」です。作れることと、止まらずに回し続けることは別の能力だからです。
「AI開発会社 おすすめ」で検索すると、会社を並べた比較記事が出てきます。ただ、そこに並ぶ順位は、自社の状況とは無関係に決まっています。この記事では、順位で選べない理由と、面談で確かめるべきことを整理します。
株式会社TOEはAI開発を事業としており、この記事を書いている立場は発注される側です。利害関係者が書いています。 そのうえで、自社でAIメディアを2本作って毎日無人で動かしている実測と、実際に起きた事故を材料に書きます。
なぜ「おすすめ一覧」で選べないのか
理由は単純で、AI開発の費用と難度を決めるのは、機能ではなく前提だからです。
同じ「問い合わせ対応をAIにしたい」でも、次のどれを選ぶかで見積もりは何倍も変わります。
| 前提 | 選択肢 | 効いてくるもの |
|---|---|---|
| 運用を誰が持つか | 自社で持つ / 開発会社に委ねる | 最も金額に効く。委ねるなら月額の保守費用が乗り続ける |
| 処理量とモデル | 少量・軽量モデル / 大量・高性能モデル | 同じ機能でも従量課金の単価が変わる |
| どこまでが「完成」か | 動くものを納める / 現場で使われる状態にする | 後者は運用設計とデータ整備が要る |
この3つを決めずに複数社へ相見積もりを出すと、各社が別々の前提で見積もるので、金額だけを横に並べても比較になりません。詳しくはAI開発の見積もりはなぜ会社によって何倍も違うのかに分解しています。
つまり選定の順番は「会社を探す → 見積もりを取る」ではなく、「前提を決める → その前提に合う会社を探す」です。
運用を自社で持つか、委ねるか
この一点で、選ぶべき相手が変わります。
| 自社で運用を持つ | 開発会社に委ねる | |
|---|---|---|
| 適した相手 | 引き継ぎやすい構成で作る会社 | 稼働の責任範囲を契約に書ける会社 |
| 確かめること | 使っている技術が一般的か。設定を自分たちで変えられるか | 障害時の連絡経路と復旧の目標時間。誰が当番か |
| 費用の形 | 初期費用が中心。運用は自社の人件費 | 初期費用＋月額の保守費用が続く |
| リスク | 担当者が辞めると止まる | 相手が廃業・撤退すると止まる |
どちらが正しいという話ではありません。社内にPCを触れる人が1人もいないなら委ねるしかなく、逆に情シス担当がいるなら自社で持つ方が総額は安く済みます。
なお「委ねる」を選ぶ場合、特定のサービスに深く依存する構造が生まれます。その リスクはAIベンダーに依存して身動きが取れなくなる構造に整理しました。
面談で聞く7つの質問
比較記事の順位より、この7つの答えの方が判断材料になります。
| # | 質問 | なぜ聞くか |
|---|---|---|
| 1 | 自社で作って運用しているものはありますか | 作った経験と、動かし続けた経験は別物。後者がないと運用設計が甘くなる |
| 2 | 過去に止まった事故はありますか。どう気づきましたか | 事故の有無より「気づく仕組みがあるか」。エラーが出ない止まり方が実際にある |
| 3 | この機能の運用は誰が持ちますか | 最も金額に効く前提。曖昧なまま進むと後で揉める |
| 4 | 処理量が増えたら費用はどう変わりますか | 従量課金が乗る構造なら、成功したときに費用が跳ねる |
| 5 | 納品後、設定を自社で変えられますか | 変えられないと、小さな修正のたびに発注が必要になる |
| 6 | 使っているのは一般的な技術ですか | 独自すぎると、他社に引き継げなくなる |
| 7 | データはどこに置かれますか | 顧客情報や図面を扱うなら、外部を経由するかどうかが要件になる |
2番目が効きます。 事故を隠す会社より、事故の内容と対処を具体的に話せる会社の方が信用できます。
「動かし続けた経験」がなぜ効くか — 自社の失敗から
当社が実際にやらかした例を書きます。
自社メディアの記事要約を一括処理したところ、553件のうち414件（75%）が失敗しました。原因は技術的に高度なものではなく、「どのAIモデルを使うか」をスクリプトに書き忘れただけです。上位モデルが使われて利用枠を食い潰し、社長本人の作業と、動いていた分析処理3本まで巻き添えで止まりました（詳細はAI処理414件を失敗させた話）。
さらに厄介だったのは、日次処理が3日間止まっていたのに誰も気づかなかったことです。監査ログを見に行ったら、肝心の記録が残っていませんでした。
ここから分かるのは、AI開発で難しいのは「作ること」ではなく「エラーも出さずに止まっている状態に気づくこと」だという点です。処理は最後まで走り、ログにも「完了」と出て、数字が増えないことだけが唯一の兆候になります。これは実際に運用した経験がないと設計に織り込めません。
だから質問1と2が効きます。自社で動かし続けている会社は、この種の失敗を必ず経験しています。
自社で作って運用している実測
判断材料として、当社が自社で作って動かしているものの実数を出します。受託案件ではなく自社プロダクトなので、金額ではなく規模と稼働の実数です。
| 項目 | 実測（2026年8月1日時点） |
|---|---|
| 無人運用しているメディア | 2媒体（ai-oni.com / uchuchu.tech） |
| 記事数 | 211本（うち一次記録60本） |
| 収集しているニュース | 保持3,000件・1日2回更新 |
| 運用中のAI API従量課金 | 0円（収集は無料の公開API/RSS、翻訳と要約はローカルCLI、配信はGitHub Pages） |
| AIで自動化した社内業務 | 27本 |
「API課金ゼロ」の構成の中身はAPI課金ゼロでAIメディアを2本動かすに、費用の3層構造はAI導入費用の相場と内訳に書いています。
この記事で言えないこと
- どの会社が良いかは書けません。 当社は発注される側で、他社を評価する立場にありません
- 相場の金額も出していません。 前提によって何倍も変わるため、単一の数字を出すと誤解を招きます
- ここに書いたのは、当社が自社で動かして分かったことと、実際に起きた失敗だけです
まとめ
- AI開発会社は「おすすめ一覧」で選べない。費用と難度を決めるのは機能ではなく前提だから
- 選定の順番は「会社を探す → 見積もりを取る」ではなく、「前提を決める → その前提に合う会社を探す」
- 分かれ目は運用を自社で持つか委ねるか。前者なら引き継ぎやすい構成で作る会社、後者なら稼働の責任範囲を契約に書ける会社
- 3つの前提（運用の所在・処理量とモデル・どこまでが完成か）を決めずに相見積もりを取ると、各社が別の前提で見積もるので比較にならない
- 面談で効くのは「自社で作って運用しているものはあるか」と「止まった事故はあるか、どう気づいたか」の2つ
- AI開発で難しいのは作ることではなく、エラーも出さずに止まっている状態に気づくこと。運用経験がないと設計に織り込めない
- 当社は自社で2媒体を無人運用し、運用中のAI API課金は0円。553件中414件を失敗させた事故も公開している
この記事の立場 株式会社TOEはWeb制作とAI開発を事業としており、この記事は発注される側が書いています。中立の第三者ではありません。そのうえで、他社の評価はせず、自社で実測した数字と実際に起きた失敗だけを材料にしています。
実測値の出所 株式会社TOEが運用する ai-oni.com / uchuchu.tech のリポジトリと日次実行ログ（2026年8月1日時点）
