フラクショナルCTOとは？依頼するタイミングと契約、解約後も自社で技術判断を続けられる仕組みの作り方とは？

フラクショナルCTOは、週1〜2日など時間の一部だけCTOの役割を担う外部の専門家です。技術顧問・CTO代行・暫定CTOとの違い、依頼するタイミング、契約の3つの形、最初の90日ですること、その人がいなくなっても自社で技術の判断を続けられる仕組みの作り方を、CTOのいない会社を間近で見てきた立場から解説します。

2026年10月10日

執筆者

運営者・AIエンジニア／ IT歴36年以上

フラクショナルCTOとは？依頼するタイミングと契約、解約後も自社で技術判断を続けられる仕組みの作り方とは？

フラクショナルCTOは「助言する人」ではなく「CTOの役割そのものを、週1〜2日など時間の一部だけ担う人」です。技術顧問・CTO代行・暫定CTOとの違いは、「役割を担うか」と「フルタイムか」の2点で見分けられます。
依頼するタイミングは、技術の判断が社長に集まり続けている、システム全体に責任を持つ人がいない、外注先を選ぼうとしている、といった状況が2つ以上そろったときです。
解約後も技術判断と開発体制を会社に残すには、最初の90日で「意思決定の記録」「プログラムの保管場所を自社が持つこと」「定例の点検」を仕組みにし、契約の最初から引き継ぎまで決めておきましょう。

フラクショナルCTOとは何か

フラクショナルCTOは、CTOの役割を、フルタイムではなく時間の一部だけ、業務委託で担う外部の専門家です。CTO（最高技術責任者）とは、会社の技術の方針と開発体制に最終責任を持つ経営幹部のことです。「フラクショナル（fractional）」は「一部の」「分数の」という意味の英語で、1人の専門家が複数の会社を掛け持ちし、それぞれの会社に時間の一部を割り当てる働き方を指します。業務委託とは、社員として雇うのではなく、会社の指揮命令を受けずに仕事を引き受ける契約のことです。

典型的な関わり方は「週1〜2日」や「月に数日」です。契約は、毎月決まった金額を払って決まった日数の仕事をしてもらう「リテイナー（月額顧問料）」の形か、稼働した日数で払う形が一般的で、3〜6か月以上の継続を前提にすることが多いです。「週に数時間から数日」が典型とされ、長い関係は数年に及ぶこともあります。

「外部CTO」「非常勤CTO」「CTO顧問」「CTO代行」などと呼ばれることもあります。呼び名はばらばらですが、中身を見分ける基準は2つだけです。「役割そのもの（ポジション）を担うか」と「フルタイムではないか」です。この2つを満たすものが、フラクショナルCTOです。

技術顧問・CTO代行・暫定CTO・コンサルタントとの違い

似た言葉が多いので、違いを整理しましょう。

形	何をするか	関わり方の目安
技術顧問	特定の技術分野（設計、セキュリティ、クラウドなど）への助言とレビュー。実行の責任は持たない	月1回の会議やその場限りの相談。月数時間〜10時間程度
フラクショナルCTO（外部CTO・CTO代行）	技術戦略の立案、採用の評価、開発チームの管理。経営陣の一員として意思決定と実行に踏み込む	月の一定時間を自社のCTO業務に充てる。月20〜50時間程度
インテリムCTO（暫定CTO）	急にCTOが抜けた穴を埋める、一時的なフルタイムの代役	3〜6か月、1社にフルタイムで関わる
コンサルタント	外から分析と提案をする。プロジェクト単位	案件ごと
開発パートナー（元請）	技術の選定から設計、品質管理まで丸ごと任せる外部の会社	継続的な委託

技術顧問は「外から助言する人」で、基本的に実行はしません。フラクショナルCTOは「中に入って役割を担う人」です。「相談の電話には応じるが継続的な責任は持たない」形を「技術コンサルティング」と呼び、フラクショナルCTOとははっきり区別されています。「この技術判断で合っているか」だけなら技術顧問で足り、「技術判断をして、実行まで見てほしい」ならフラクショナルCTOを選びます。

なお、「CTO代行」という言葉は、技術顧問とフラクショナルCTOのどちらの意味でも使われています。サービス名で判断せず、「役割を担うのか、助言だけなのか」を契約の前に言葉で確かめましょう。CTO代行という選択肢の全体像と、選ぶときの失敗例は、CTOがいない会社の技術判断は、CTO代行という選択肢で変わるで説明しています。

CTOがいない会社で、実際に起きていること

そもそも、なぜCTOが重要なのでしょうか。CTOがいない会社では、主に3つのことが起きます。技術の判断が止まる・1人に偏る（特定のエンジニアや外注先に丸投げになり、その人が離れると意思決定が止まる）、外注先の提案を評価できない（割高な保守費用や、特定の会社から離れられなくなる設計を見抜けない）、そして技術的負債が知らない間に積み上がっていく、の3つです。技術的負債とは、急いで作ったり手入れを怠ったりしたために、あとで直すのに大きな費用がかかる状態のことです。

私は36年以上IT業界で働き、CTOのいない会社で何が起きるかを間近で見てきました。最も多いのは、社長が「この提案は技術として筋が通っているか」を見分けられないため、外注先が言う金額も説明も疑わずに受け入れてしまうケースです。何年かたってから、保守料が高すぎることや、もう身動きが取れない仕組みになっていることに気づく、という流れです。社内でシステムの中身が分かる人が1人だけで、その人が去った瞬間に誰も手を付けられなくなった会社も、複数見てきました。

AIが普及してからは、新しい問題も増えています。AIの仕組みを知らないまま導入して収拾がつかなくなる、AIの間違った回答に誰も気づかず顧客に伝えてしまう、AIのチャットに顧客情報を入力してしまう、といったものです。どれも「技術の判断に責任を持つ人がいない」という同じ問題から起こっています。

なお、「CTOがいない」と「技術担当者がいない」は別の問題です。CTOは、技術の全体方針を決め、システムの構造（アーキテクチャ、つまりどんな部品をどうつなぐかの設計）を決め、外部の提案を評価し、チームをまとめる役割です。プログラムを書ける人が社内にいても、この役割が空席なら、上の3つの問題が起きるのです。

どんなときに頼むか、頼まないか

依頼するタイミング

「依頼するタイミング」は5つあり、2つ以上そろったときが目安です。

技術の判断が、創業者（社長）に集まり続けている
チームは作れるが、システム全体に責任を持つ人がいない
試作品から本番運用へ、規制のある市場へ、大口顧客のセキュリティ審査（情報の守り方に穴がないかの点検）へ、といった節目が来た
開発パートナー（外注先）を採用・評価しようとしている
投資家・顧客・取締役会が、信頼できる技術計画を求めている

私の実感では、4番目の「外注先を選ぶとき」がいちばん分かりやすいタイミングです。見積もりの妥当さは、経験がないと読めません。目を引くほど安い見積もりは、たいてい重要な作業が省かれています。反対に高すぎる見積もりは、「念のため」の費用が加算されていることがほとんどです。私は見積もりを受け取ったら、設計・実装・テスト・保守にどれだけの工数が見積もられているか、その配分が無理のないものかを最初に確かめます。この「割合を読む」判断が社内でできないなら、依頼するタイミングです。

依頼しないほうがよい場合

フラクショナルCTOが合わない状況についても、確認してみましょう。

必要なのが「開発の手数（人手）」のとき。必要なのは技術判断ではなく作業です
毎日の人とデリバリー（納品・リリース）の管理が必要なとき。これはCTOではなく、開発チームの人と進め方を毎日管理する責任者（VP of Engineering、略してVPoE）やエンジニアリングマネージャーの仕事です
1つの専門的な答えだけが要るとき。技術顧問や専門家への相談で十分です
社長が技術判断を委ねる気がないとき。役割を渡さなければ、機能しません

「すでに50人以上のエンジニアを抱えている会社」「課題が方向性ではなく主に実行フェーズにある会社」は、向いていないと言えるでしょう。

正社員のCTOに切り替える目安

社内のエンジニアが0〜5人ならフラクショナル、5〜12人ならフラクショナルか移行を毎月見直し、12人以上ならフルタイムのCTOが必要と判断できます。もう1つのポイントは、技術が「事業を支えるツール」なのか「技術そのものが事業」なのかです。前者ならフラクショナル、後者ならフルタイムが合います。資金調達の面では、シリーズB（初期のシード・アーリー期を過ぎた成長段階）までに、フルタイムCTOが必要とされています。

「週2日を超える支援が継続して必要になったら、フルタイム採用への切り替えを推奨する」という基準もあります。一時的に週3日に増やすことはできても、それが続くなら形を変えるべき、という考え方です。フラクショナルCTOは、正社員のCTOを採用するまでの過程であって、終点ではないのです。

どの形で依頼するか

契約の3つの形

契約の形は、3つに分けて考えましょう。

アドバイザリー・リテイナー: 月額固定の範囲で、決まった日程に技術判断のレビューをする。優秀なシニアチームがすでにいる会社向けです。弱点は、チームを変える、実行を続ける、といった手が足りないことです
オペレーティング・フラクション: 毎週決まった日数を確保し、技術ロードマップ（事業の目標に合わせて、いつ何を作る・直すかを並べた計画表）・設計・採用・リスクを継続して担う。決定権と、連絡が取れる時間を文書で決めておく必要があります
インテリムCTO: 空席・買収前の調査・立て直し・移行のために、高い稼働で期間を決めて入る。引き継ぎの計画を早めに決めます

社内に技術責任者がいない中小企業・スタートアップに合うのは、ほとんどの場合2番目です。1番目は「見てくれる人がいる」安心感はありますが、助言を受け取って実行する人が社内にいなければ、何も変わりません。

稼働の単位

稼働は「週1〜2日」か「月○日」などと表現されます。月2〜4日・月8〜12日・月15日以上の3段階に分け、最初は3〜6か月のトライアル期間を設けるのが一般的です。副業・フリーランスのCTO案件でも、週1日の内製化支援から週2〜3日のクラウド選定支援まで幅があり、週2〜3日の案件が多いとされています。

フラクショナルCTOの費用は、一般に「フルタイムCTOの総人件費の20〜40%程度」とされ、日本では公的な統一料金表や統計はなく、稼働日数に応じて個別の見積もりで決まります。報酬のほかに、遠方からの来社の交通費（実費精算が一般的）や、採用エージェントの費用（原則として会社が負担）がかかることがあります。金額を比べる前に、「何日来てもらい、何を担ってもらうか」を先に決めましょう。そこが曖昧なまま金額だけで比べると、時間の短い、助言だけの契約を選びがちです。助言だけの契約では、CTOは意見を言うだけで、決めるのも責任を持つのも、これまでどおり社長になります。「技術の判断を任せられる人がいない」という最初の問題は、そのまま残ります。費用を決めるポイントと、高い安いの見分け方は、技術顧問の費用は月いくらか、決まる3つの要素と高い安いの見分け方で説明しています。

形を決めるときに、私が基準にしていること

私は日本でASP事業（アフィリエイト広告の仲介サービス）を始めた際、はやりの新しい技術をわざと避け、昔から多くの人が使っていて解説も豊富な技術を土台に作りました。その方が人を採りやすく、1人だけが中身を知っているという状態に陥りにくいからです。この選択のおかげで、担当が何度代わってもシステムは動き続け、何年も運用を続けた末に事業そのものを売却できました。技術を選ぶ基準は「新しいか」ではなく「誰でも触れるか」です。

フラクショナルCTOに頼むときも、同じ基準が使えます。「その人がいなくなっても同じように継続できるか」です。1人の外部の専門家が技術判断をし、その人にだけ知識がたまる仕組みでは、外部の1人に依存する危険な状態になります。次で説明する、「技術判断を会社に残す仕組み」を契約に入れましょう。

どう依頼すれば、解約後も技術判断と開発体制が会社に残るか

フラクショナルCTOに頼んで成果が出る会社と出ない会社の差は、「技術判断を会社に残す仕組み」を最初から作ったかどうかで決まります。

最初の90日で実践すること

最初の90日の進め方は、次のとおりです。

最初の30日: 製品・システムの構造・外注先・チーム・リスクを把握する。意思決定ログ（何をいつ誰がなぜ決めたかを書き残す記録）を作る。担当者を決める。急ぐリスクと後回しでよい改善を分ける
31〜60日: 事業の成果に結びつけた技術ロードマップを書く。作る・買う・捨てる・先送りにする、を決める。確認する指標を少数に絞る
61〜90日: 定例会議で技術の方針を決める習慣を作る。障害対応・リリース・外注先の見直しの手順を実際に試す。フラクショナルの範囲が今も合っているかを見直す

日本のサービスでも、契約の最初に2〜4週間、固定料金で今のシステムと体制を調べ、提案・計画の案・その後の契約範囲を出す流れを取っています。

私はこの工程を、どんな案件でも必ず設けています。きっかけは、資料が一切なく、プログラムにも説明がほとんど書かれていないシステムを引き継いだ経験です。その時は、プログラムを一行ずつ読み解くところから始めるしかありませんでした。それ以来、引き継ぎの案件では、最初の工程の目的を「現状を見えるようにすること」だけに絞っています。改善の提案は、見えるようになってからです。

技術判断を文書で残す

フラクショナルCTOの技術判断は、文書に残すことが重要です。方法は3つです。

ADR（Architecture Decision Record）を書く。設計上の判断と、その理由と、選ばなかった案を1件ずつ記録する文書です。なぜその技術を選んだのかが残っていれば、担当者が代わっても技術判断の筋道をたどれます
技術方針の文書を定期的に更新する。一度書いて終わりにしません
月1回、外部CTOや技術顧問を交えた技術会議を行う。技術判断を「その場の会話」で終わらせず、会議の記録に残します

私は、1000万円級の開発をいくつも担当してきました。その中で効果が大きかったのは、要件をまとめた書類とは別に「やらないことの一覧」を作り、依頼者と制作者が着手前に確認し合ったことです。途中で「これも」「あれも」と要望が足されて範囲が広がるのを、この一覧で止められました。反対に、役割や分担をはっきりさせずに契約し、動き始めてから「聞いていた話と違う」とトラブルになったこともあります。以後は、速さや障害対応の条件も、数字で書面に残しています。「決めたこと」だけでなく「決めなかったこと」「約束した水準」も記録に残すことが重要です。

開発体制の主導権を会社が握る

外注先に開発を任せるときに、会社側が最低限守るべきルールが4つあります。

ソースコードのリポジトリを、発注者である自社が保持する。ソースコードはプログラムの元になる文字で書かれた設計図そのもので、リポジトリはそれを変更の履歴ごと保管する場所です（Gitがその代表的な道具です）。これが外注先の手元にしかないと、別の会社に乗り換えることも、中身を点検することもできません
システム構成図とインフラ（サーバーやネットワークなどの土台）の設定書を、成果物として契約に定義する。サーバーとは、プログラムとデータを動かすコンピューターのことです
開発標準（プログラムの書き方のルールと、動作確認のやり方の方針）を、契約前に文書にする
定期的なコードレビュー（書かれたプログラムを別の人が読んで点検すること）を開発の工程に組み込む

外注先から報告を受けるときの確認点も4つあります。進捗をタスク単位で確認できるか、問題を早めに報告するか、テスト結果や品質の指標を示すか、変更の影響範囲を説明できるか、です。

私は日本とフィリピンで、国内の開発会社にも現地の開発チームにも仕事を頼み、その進み方を管理してきました。成果が出た案件には共通点があり、毎週1回の進捗状況の共有に加えて、実際に動く画面を必ず見せてもらっていました。認識違いがあっても早い段階で気づいて直せます。うまくいかなかった案件は、書類だけ渡して放っておいたものです。納品の間際になって、思っていたものとは別物が出てきました。「進んでいます」という言葉ではなく、動くものを定期的に見せてもらうことで、進み具合を自分で判断でき、開発の主導権が会社に残ります。

もう1つ、重要なバックアップについてです。私が経験した中で最も重かった障害は、ディスクが壊れたことでした。控えのデータが本当に使えるかを確かめていなかったため、元に戻すまでに丸一日以上を費やしました。その後は、「バックアップから本当に元に戻せるか」を定期的に確認するようにしています。最初の90日の「障害対応の手順を実際に試す」という項目は、こういう意味です。手順書どおりに実行して結果が出るかを確認しましょう。

特定の会社から離れられないリスクを避ける

ベンダーロックインとは、特定の開発会社やサービス（ベンダー）から離れられなくなる状態です。私自身、日本で動画配信サービスを制作した時に、ある安いデータベースに依存した設計にして失敗したことがあります。後になって別のサービスへ乗り換えようとしたところ、ほぼ全体を作り直すことになりました。この経験から、「このシステムや業者から抜けられなくなったら、いくらかかるか」を、見積もりを読む時点で必ず計算に入れています。

フラクショナルCTOに頼むなら、「自社で開発するか、既製のサービスを使うか」の判断を、この視点で見てもらってください。私は「その部分が、ほかの会社との差になるか」という基準で判断します。経理や勤怠の管理のような作業には、既製サービスが向いています。反対に、サービスの核となる部分は自社で作りましょう。

契約を終了するタイミングを決めておく

フラクショナルCTOに依存し続けない体制が重要です。そのために、契約を終了するタイミングをはじめに計画しておきましょう。

私がこの考え方を強く持つようになったのは、ライブドアが私の事業を買収した時の経験です。ライブドアは、その事業が継続して運営できるかを念入りに調べました。中でも「担当者が抜けても事業は回るのか」という部分は重要でした。契約の内容は、買収されたあと私がその事業部に入り、2年間は運営の指揮を執る、というものでした。つまり、最初から「2年後は契約を終了する」という内容だったのです。フラクショナルCTOも、はじめから契約を終了するタイミングを決めておく必要があります。

契約で決めること

契約時に決めておくべき項目を紹介しましょう。

何を任せるか（役割）: これを先に定義します。「何を任せるか」が曖昧だと、成果が出ません
月の稼働日数・時間と、期待する成果・KPI（成果を測るために決める数字の目標）
権限と責任の設計: どこまでの意思決定を委ねるか。掛け持ちが前提なので、稼働時間と優先度の合意も含めます
既存社員との役割分担: 「置き換え」ではなく「補完」として設計します
情報・機密の取り扱い: NDA（守秘義務契約。知った秘密を外に漏らさないと約束する契約）と、運用ルール
知的財産権の帰属、競業避止条項、契約解除の条件（解除の手順と通知期間）、報酬額と支払い条件

重要なのは、「小さく始め、段階的に関与を深める」ことです。最初から週3日で頼む必要はありません。

依頼する相手を見抜くときの注意

CTOを選ぶときの基準としては、業界経験と事業内容の一致、技術の適合性、経営目線での対話力、採用支援の力、測定できる成果への責任感の5つです。

依頼するCTOを見抜くときの注意は3つです。1つ目は、開発の受注・クラウドの再販・人材紹介でも収入を得ているのに、それを明かしていない人です。助言がそのビジネスに有利な方向へ傾くおそれがあります。2つ目は、面接での説明は上手でも、長く責任を持って技術を見てきた実績がない人です。3つ目は、約束した役割に対して、使える時間が少なすぎる人です。そして依頼する側にも注意があります。いったん合意した技術判断を、社長が後から蒸し返したり、相談せずに別のやり方を進めたりすると、役割を任せたことになりません。

私は日本とフィリピンで、数十名を面接し、採用の判断をしてきました。話し方の印象が良いというだけで採用し、いざ現場に入ると求める水準になかった、という苦い経験もあります。その後は、実力を確認できる課題を出すようにしています。また、自分が失敗した案件を、何がどう悪かったかまで具体的に語れる人は、現場の力が高い傾向があります。フラクショナルCTOを選ぶときも、成功の話ではなく、失敗の話を聞いてください。

よくある質問

Q: 技術顧問とフラクショナルCTOは、どちらに依頼すべきですか？

社内に、助言をもとに実行できる技術責任者がいるなら技術顧問で十分です。もしいないなら、フラクショナルCTOに依頼しましょう。技術顧問は外部から助言する人で、実行の責任は持ちません。フラクショナルCTOは経営陣の一員として役割を担い、意思決定と実行に責任を持ちます。「相談に乗ってもらう」だけで現場が変わらなかった経験があるなら、フラクショナルCTOに依頼しましょう。

Q: フラクショナルCTOがいなくなったあとに、会社だけで技術の判断を続けられるようにするには？

意思決定ログやADRで技術判断と理由を文書に残す、ソースコードのリポジトリを自社が持つ、月1回の技術会議を定例にする、の3つを契約に入れてください。この仕組みがあれば、フラクショナルCTOを解約した後でも、会社だけで技術の判断を続けられるようになります。

Q: 正社員のCTOを採用するまでのつなぎとして頼んでもよいですか？

その依頼方法がおすすめです。フラクショナルCTOは「フルタイムCTO採用」への過程です。まずは仕組みを作ってもらい、正社員のCTOを採用したらアドバイザーになる、という契約にしておきましょう。引き継ぎの期間（4〜8週間など）を最初から契約の範囲に含めておくのもおすすめです。

まとめ

フラクショナルCTOは、週1〜2日など、時間の一部だけCTOの役割を担う外部の専門家です。

依頼するタイミングは、技術の判断が社長に集まり続けている、システム全体に責任を持つ人がいない、外注先を選ぼうとしている、といった状況が2つ以上そろったときです。

依頼する場合は、毎週決まった日数を確保してもらう契約が、技術責任者のいない会社には合います。最初の90日で現状を把握する、決めたことを文書に残す、ソースコードを自社で持つ、動くものを見せてもらう、定例会議を習慣化する、引き継ぎまで契約で決めておく、などが重要です。

フラクショナルCTOにサポートしてもらいながら、自社でも技術判断ができるような仕組みを作りましょう。ここが、フラクショナルCTOに依頼して成果が出るかどうかの重要なポイントです。

PH Tech AIは、社内に技術責任者がいない中小企業・スタートアップに、CTO代行・技術顧問サービスを提供しています。外注先の見積もりの妥当さ、ベンダーロックインの回避、スムーズなAI導入などをサポートします。技術判断に不明な点があれば、無料でご相談いただけます。まずはお気軽にお問い合わせください。

参考・出典

フラクショナルCxOとは？定義・他の形との違い・依頼のポイント（talental）: https://talental.jp/media/2026/07/01/fractional-cxo/
Fractional CTO（用語集。責任・インテリムCTOとの違い・費用の比率）（Mad Devs）: https://maddevs.io/glossary/fractional-cto/
Fractional CTO Guide（担う仕事・フラクショナル／インテリム／フルタイムの比較・求める資質）（ELIFTECH）: https://eliftech.com/insights/fractional-cto-guide
CTO顧問とは（定義・技術顧問との違い・稼働の3段階・契約で決める項目・選び方）（顧問制度ガイド）: https://komonseido.com/guide/knowhow/cto-komon/
CTOがいない会社の開発（起きること・技術顧問と外部CTOの違い・技術判断を残す仕組み・発注のルール）（LASSIC）: https://lassic.co.jp/media/column/development-without-cto/
When to Hire a Fractional CTO（頼む合図・頼まない場合・契約の3つの形・最初の90日・見抜く注意）（RaftLabs）: https://www.raftlabs.com/blog/when-to-hire-fractional-cto
非常勤CTO（Fractional CTO）サービス（稼働・契約の流れ・向く企業・費用の比率・引き継ぎ）（Gradion）: https://gradion.com/ja/solutions/interim-leadership/fractional-cto
Fractional CTO vs Full-Time CTO Decision Guide 2026（人数の目安・契約期間・出口の設計）（Groovy Web）: https://www.groovyweb.co/blog/fractional-cto-vs-full-time-cto-decision-guide-2026
副業・フリーランスのCTO案件の例（稼働の幅）（flexy）: https://flxy.jp/media/article/8443