AIの案件は、要件が固まりきらないまま始まることが少なくありません。だからこそ、どの段階で何を決め、どこまでを契約に書くのかを、最初に共有しておく必要があります。
このページでは、初回のご相談から運用・保守までの流れと、6つの契約形態の違い、検収・知的財産・変更管理の考え方をまとめています。
日本のお客様との契約は株式会社Technica AI（東京・神田）と締結いただきます。窓口は、日本法人が日本語で担当します。
多くの案件はPoCから開始し、効果を確認したうえで本開発へ進みます。本開発に進まないという判断になった場合も、その理由を含めて報告します。
汎用部品・既存製品は除きます。契約形態ごとの扱いは、下記の「6つの契約形態」に記載しています。
案件の規模や契約形態によって、省略するステップや順序が入れ替わるステップもありますが、基本的にはこの流れで進みます。各ステップで何を決め、誰が何を出すのかを先に共有します。
課題、対象業務、時期感をお聞かせください。実現可能性について、その場で分かる範囲をお答えします。
具体的な資料やデータを拝見する前に、秘密保持契約を締結します。貴社の様式をそのままご利用いただけます。
業務資料とサンプルデータを拝見しながら、解くべき課題と、先に決めておくべき論点を洗い出します。
範囲、体制、期間、費用を提案書にまとめます。見積書には前提条件書を必ず添付します。
実データを使い、合意した検証項目で成立するかどうかを確かめます。結果は達成・未達を問わず報告します。
業務要件に加え、性能、可用性、セキュリティ、運用の要件を確定し、テスト方針まで決めます。
定例で進捗と論点を共有しながら進めます。仕様の変更は変更依頼書で受け、影響を評価してから着手します。
着手前に合意したテスト仕様書と検収基準書に基づいて確認いただきます。検収の段階になってから基準を決めることはしません。
問い合わせ対応、障害対応、継続的な改善を担当します。標準のサービスレベルはサービスレベル方針に記載しており、必要な水準は個別に取り決めます。
PoCで期待した結果に届かなかった場合も、そのまま報告します。追加のPoCを行うか、条件を変えて再検証するか、本開発へ進まないか。進めないという結論も、PoCの成果です。
要件整理とご提案は、規模が大きい場合に準委任契約（要件定義フェーズ）として切り出すことがあります。その場合は、着手前に範囲と費用をご提示します。
案件の性質に応じて、製品導入、PoC、請負開発、準委任開発、ラボ型（ODC：オフショア開発センター）、共同研究の6つから選びます。どれが適切かは、初回のご相談の段階でご提案します。PoCは準委任、本開発は請負というように、組み合わせることもあります。
AIKNOW等のライセンス提供と導入支援
データで成立するかどうかを確かめる
PoCは「できます」と言うための工程ではなく、できるかどうかを確かめる工程です。
仕様と成果物を定義し、完成責任を負う
仕様を固めながら進める
専任チームを期間で確保する
製品化前のテーマを一緒に検証する
購買・法務・情報システム部門からいただくご質問を、先にまとめています。
日本のお客様との契約は、原則として日本法人の株式会社Technica AI（東京・神田）と締結いただきます。お問い合わせから納品、保守までの窓口も日本法人が担います。
契約主体は株式会社Technica AIで、案件によってはベトナムのTechnica Co., Ltd.のメンバーが従事します。グループ2社以外の企業への再委託は、原則として行っていません。
2社間では、秘密保持について連帯して責任を負う体制としています。お客様の情報は、日本法人と同一の基準で取り扱います。データの保管場所とクラウドのリージョンは案件ごとに取り決め、日本国内リージョンのみでの構成にも対応します。
開発着手前に、テスト仕様書と検収基準書を合意します。何をもって合格とするかを、検収の直前ではなく着手前に決めておくためです。
検収期間は、納品日から14日間（暦日）を標準とします。期間内にご通知がない場合は合格とみなす条項を置きます。
請負契約では、引渡しから1年以内にご通知いただいた不適合について、無償で修補します。お客様の指示や支給データに起因する場合、および仕様どおりの動作である場合は対象外です。
個別開発した部分は、ソースコードを含めて納品します。汎用部品、既存ライブラリ、製品として提供している部分はTechnica AIに権利を留保し、利用を許諾する形になります。どこまでが納品対象かは、契約書の別紙に列挙します。
特定の出力内容そのものを保証することはしません。生成AIの出力は確率的であり、入力に応じて変動するためです。
そのうえで、合意した評価データと評価基準で検証し、その基準を満たすことを検収の条件とします。基準は、業務で許容できる水準からお客様と一緒に決めます。
お客様からお預かりしたデータは、当該案件の目的以外には使用しません。外部の生成AIサービスの学習には提供しません。外部にデータを出せない環境では、オープンウェイトモデルを用いた閉じた構成にも対応します。詳しくは「情報セキュリティ体制」をご覧ください。
原則としてそのままは使いません。PoCは成立性の確認を目的としており、性能、可用性、権限管理、運用のしやすさといった非機能要件を作り込んでいないためです。本番では、PoCで得た知見をもとに設計し直します。
可能です。元請けの下で開発を担当する形、既存システムのベンダーと分担する形、いずれも実績があります。着手前に役割分担と窓口を明確にし、指揮命令の所在を書面で整理します。
当該契約の対価相当額を上限とするのが基本です。個別の事情に応じて協議します。
可能です。決算書、登記事項証明書、セキュリティチェックシートへのご回答など、ご要望に応じて提出します。
日本語・英語とも対応可能です。契約書、議事録、報告書についても、ご希望の言語で作成します。
金額そのものより、その金額が何を含み、何を含まないかを明確にすることを重視しています。
見積書には、対象範囲、対象外、前提とするデータの品質、お客様側で実施いただく作業、体制、遅延時の扱いを書いた前提条件書を添付します。その金額に何が含まれていないかを、先に明らかにするためです。
要件が固まっていない段階では、レンジでの概算をお出しし、根拠となる工数の内訳を示します。確定見積りは、範囲が確定してからお出しします。
仕様の変更は変更依頼書（CR）で受け、影響を評価したうえで期間と費用を再合意してから着手します。合意前に作業を進めて、後から請求することはしません。
工程別・機能別に分解して提示します。どこに工数がかかっているかが分からない見積りは、社内での比較も判断もできないためです。
