業務担当者はAIを使って自分でシステムを作れるか：養殖企業の1事例から見る3つの条件と5つの限界

著者注：従業員約120人の畜産企業で、総経理がAIコーディングツールを使い、自ら畜産管理システムを構築しました。この記事では「誰でも開発できる」という話を繰り返すのではなく、この事例が成立した条件と、業務担当者がAIでシステムを自作する際に避けて通れない限界を考えます。

2026年11月、烏鎮世界インターネット大会の先端技術賞の受賞結果が発表され、アリババ傘下のエージェントプラットフォームQoderが、中国国内で唯一受賞した汎用Agent製品となりました。関連報道の中に、「業務担当者も自分でシステムを作れる」と語られがちな事例があります。寧夏の畜産企業・西鮮記の総経理、張立非氏が、AIコーディングツールを使い、3か月余りで畜産管理を含む複数の業務システムを構築したというものです。

これは「未経験者が一夜にしてプログラマーになった」という話ではありません。 張氏は以前、ファーウェイやエリクソンで研究開発に携わった経験があり、自社の畜産、と畜、加工の業務にも精通していました。この2つの前提を踏まえることで、この事例から何が言えて、何が言えないのかが見えてきます。

この記事でわかること：自分の業務要件がAIを使ったシステムの自作に適しているかを判断できるようになります。また、要件の説明、成果物の確認、継続的な保守という3つのハードルについても理解できます。

業務担当者がAIを使って自らシステムを構築：事例の要点

まずは報道で確認できる事実を整理し、その意味を考えてみましょう。以下の情報はすべて、極客公園の2026年11月5日の報道に基づいています。

業務担当者がAIでシステムを自作する実際の進め方

報道には、見落としやすい点があります。張立非氏は「ひと言伝えるだけで、AIがシステムを完成させる」という使い方をしているわけではありません。複数の開発セッションを同時に開き、あるタスクの出力を待つ間に別のセッションへ移ります。AIが修正を終えたら、自分で結果を確認し、業務で新たに生じた状況を追加していきます。

これは「業務の専門家＋AIという実行役」の協働モデルといえます。要件の分解、受け入れ判断、改善の方向づけは人が担い、AIはコードの作成・修正やタスクの実行を担当します。この視点で事例を見直すと、そこから得られる示唆がより明確になります。

業務担当者が AI でシステムを作る：AI はどんなハードルを下げたのか

AI を使って社内ツールを自作することは、もともと小規模なチームで担っていた仕事を分担し直すことだと言えます。下表は、従来の受託開発における各工程を、この事例では誰が担ったのかを比較したものです。

表から分かるように、AI が最もハードルを下げたのは「明確な要件を動くコードに変える」部分と、依頼側と開発側の間で生じるコミュニケーションの負担です。張立非氏にとって、それまで最も難しかったのは、アイデアをシステムにできるチームがいないことでした。そこはまさに、AI プログラミングツールが得意とする部分です。

ただし、要件整理と成果物の検収が不要になったわけではありません。むしろ、その役割はより集中的に業務責任者に委ねられるようになりました。報道でも、Qoder の新バージョンは「目標が明確で、成果物の良し悪しを見極められる」人を対象としていると述べています。この条件は重要です。

業務担当者が AI でシステムを自作するための 3 つの前提条件

この事例から、成功に必要な前提条件を 3 つにまとめられます。

1. 問題がどこにあるか分かっている：張立非氏は「一群の羊でいくら利益が出るか、屠畜後まで分からない」ことが中核的な課題だと把握しており、要件には明確な業務上の目標がありました。
2. 要件を明確に伝えられる：「管理システムを作って」と頼むだけでなく、項目、フロー、計算ルールを説明し、確認可能な検収基準を示せます。
3. 成果物が正しいか判断できる：開発経験があるため、構造を理解して論理的な誤りを見つけられるほか、AI が意図から外れた場合にも速やかに修正できます。

この 3 つのうち、1 つ目は多くの業務責任者が備えている条件でしょう。真の分かれ目となるのは 2 つ目と 3 つ目です。開発経験がない人にできないわけではありませんが、学習に時間をかける必要があります。また、単一の事例だけでは、そうした人たちの成功率は分かりません。

🚀 クイックスタート：まずは「要件を明確に伝えられるか」を低コストで試したいなら、大規模言語モデルを使って業務の説明を構造化された要件定義書にまとめてみましょう。APIYI apiyi.com では、1 つの APIキーで複数の主要モデルを呼び出せます。小規模に試したうえで、本格的な開発に取り組むかどうかを判断するのに適しています。

業務担当者がAIでシステムを自作する前に：まずは要件を仕様書にまとめる

システムを自作するプロジェクトが失敗する原因は、AIがコードを書けないことよりも、要件そのものが曖昧なことにあります。着手する前に、まずは口頭で説明するような業務内容をモデルに渡し、データ項目・ルール・受け入れ条件に整理してもらいましょう。そのうえで、一つずつ自分で確認します。

以下は、OpenAI互換インターフェースを使ってモデルを呼び出し、業務の説明を要件仕様に変換する最小限の例です。

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

desc = "三个养殖场，按批次记录每天饲料消耗和羊的体重，想在出栏前就知道每批羊大概赚多少钱。"
resp = client.chat.completions.create(
    model="gpt-4o-mini",  # プラットフォームで利用可能な別のモデルに変更できます
    messages=[{"role": "user", "content": f"把以下业务需求整理成数据字段、计算规则和验收条件：{desc}"}]
)
print(resp.choices[0].message.content)

import openai
from typing import Optional

SYSTEM_PROMPT = (
    "你是资深业务分析师。请把用户的业务描述整理为：\n"
    "1. 核心数据实体与字段（含单位）\n"
    "2. 计算规则（写出公式）\n"
    "3. 验收条件（每条都必须可被人工检查）\n"
    "4. 需要用户补充确认的问题清单\n"
    "不要假设用户没说过的规则，不确定的地方放进问题清单。"
)

def build_spec(
    business_desc: str,
    model: str = "gpt-4o-mini",
    extra_context: Optional[str] = None,
    max_tokens: int = 1500
) -> str:
    """口頭で説明するような業務内容を、確認可能な要件仕様にまとめる"""
    client = openai.OpenAI(
        api_key="YOUR_API_KEY",
        base_url="https://api.apiyi.com/v1"
    )
    content = business_desc
    if extra_context:
        content += f"\n补充背景：{extra_context}"

    try:
        resp = client.chat.completions.create(
            model=model,
            messages=[
                {"role": "system", "content": SYSTEM_PROMPT},
                {"role": "user", "content": content},
            ],
            max_tokens=max_tokens,
        )
        return resp.choices[0].message.content
    except Exception as e:
        return f"调用失败：{e}"

if __name__ == "__main__":
    spec = build_spec(
        business_desc="按批次管理在栏羊，记录每日饲料消耗、体重和生长阶段，"
                      "希望出栏前估算每批羊的成本和利润。",
        extra_context="目前用 Excel 台账，有三个养殖场。"
    )
    print(spec)

このコードがシステムを開発してくれるわけではありません。その価値は、「説明できたつもりでも、実は十分に伝わっていなかった」点を明らかにすることにあります。モデルが提示する質問リストが長いほど、AIコーディングツールに実装を任せる前に、要件をさらに整理する必要があるということです。

業務担当者は AI でシステムを自作できる？適用可否を判断するフレームワーク

この事例から、条件がそろえば、業務担当者が AI を使って社内システムを自作できることがわかります。ただし、すべてのシステムが自作に適しているわけではありません。以下のフレームワークを使えば、まず自作できるものと、専門チームの関与が必要なものを切り分けられます。

西鮮記の養殖管理システムは、おおむね左側に当てはまります。社内で使用し、給餌や出荷の判断に役立てるもので、問題が起きても誰かがすぐに気づけます。あなたのニーズも同じようなものであれば、AI による自作は試す価値のある選択肢です。一方、右側に複数当てはまる場合は、まず AI でプロトタイプを作って要件を明確にし、そのうえで専門チームに依頼するか、実績のある製品を導入するほうが堅実です。

業務担当者による AI での自作、製品導入、カスタム開発の比較

3つの選択肢を並べてみると、違いがよりわかりやすくなります。

3つの選択肢は、どれか1つに絞る必要はありません。よくある組み合わせとして、まず AI で自作して業務フローを動かし、ニーズが本当にあるか検証する方法があります。その後、ユーザーが増えたり、扱うデータの機密性が高くなったりした段階で、専門チームに再構築を依頼するかを判断します。

ビジネス担当者がAIでシステムを自作することの影響分析

中小企業の経営者への影響

• チームがないために要望を見送る必要がなくなる：西鮮記のように技術開発担当者が1人しかいない企業は、これまで「自社に合わない汎用ソフト」と「高額なカスタム開発」の二択を迫られていました。今は、新たに試せる選択肢が加わっています。
• 業務知識の価値が高まる：業務を最もよく知る人が、自らの経験を直接システムに反映し、日々使いながら改修できます。これにより、「要件を伝える」過程での情報の欠落を減らせます。
• 経営者の時間的コストが増える：報道によると、張立非氏は仕事の後や出張の合間に開発を進めていました。こうした時間の投入もコストであり、単純に「0コスト」とは見なせません。

専門の開発チームやIT部門への影響

• 役割が「コードを書く」ことから「支える」ことへ変わる：ビジネス担当者が自作するツールが増えると、セキュリティレビュー、権限設計、データのバックアップ、システム連携などに専門家の関与がより必要になります。
• シャドーシステムのリスクが高まる：各業務部門がそれぞれAIでツールを構築すると、データの分散や集計基準の不統一、担当者の退職後に保守できる人がいなくなるといった問題が生じます。事前にルールを整備する必要があります。

この事例ではまだ答えが出ていない5つの問い

報道では成功した結果が紹介されていますが、意思決定者にとっては以下の情報も重要です。現在公開されている資料では、これらは明らかになっていません。

これらの問いに答えが出るまでは、この事例を「誰にでもできる」証拠ではなく、「条件が整えば実現できる」証拠として捉えるのが、より妥当でしょう。

よくある質問 FAQ

業務担当者が AI でシステムを自作する際のポイント

• 事例には前提がある：主人公は開発経験と深い業務知識の両方を持っており、単純に「誰でも開発できる」とは言えません。
• AI が下げるのは実装のハードル：コーディングや改善は速くなりますが、要件整理と成果物の検証は引き続き人が担います。
• まず自作に向いているシステム：社内利用で、機密性の高いデータを扱わず、間違いを人手で修正できるツール。
• 専門家の関与が必要なシステム：個人情報、決済、複雑な権限管理、複数システムとの連携を伴うもの。
• 見えにくいコストも見逃せない：作業時間、ツールの費用、長期的な保守をすべて判断材料に含める必要があります。
• 投資の前に検証を：APIYI apiyi.com を通じて低コストでモデルを呼び出し、要件仕様を整理したうえで、自作・購入・カスタム開発のいずれにするかを決められます。

まとめ

西鮮記の事例は、業務責任者が問題の所在を把握し、要件を明確に伝え、成果物を判断できれば、AI コーディングツールを使って、これまで棚上げされていたシステムを実現できることを示しています。重要なポイントは次の3つです。

1. ハードルは確実に下がっている：要件から動作するコードを作るまでの工程では、AI がすでに大部分の作業を担えます。
2. 判断力は代替できない：要件の記述、成果物の確認、継続的な保守は、引き続き業務を理解する人が担当します。
3. 境界は事前に明確にする：データセキュリティ、権限管理、長期的な保守を踏まえ、自作できるシステムと専門チームが必要なシステムを見極めます。

AI を使った社内ツールの自作を検討しているなら、まずは失敗の影響が小さい業務フローから始めるのがおすすめです。AI で要件を仕様にまとめ、プロトタイプを作り、その結果を見て次のステップを決めましょう。APIYI apiyi.com なら、1つの APIキーで複数の主要モデルを比較し、手早く効果を検証できます。

📚 参考資料

1. 极客公园 – 世界インターネット大会の先進技術賞受賞の裏側：Qoder はなぜ中国の AI プログラミング市場で首位を獲得できたのか：本記事の事例に関する情報源
2. リンク： geekpark.net/news/373542
3. 説明： 西鲜记の養殖管理システムの事例や、吉利、山大华天などの企業による AI プログラミングの実践を紹介

著者: APIYI 技術チーム
技術交流: モデル呼び出しや社内ツールとの連携についてのご質問は、APIYI のウェブサイト apiyi.com のトップページからお気軽にお問い合わせください