Does building a new app or website qualify as R&D?

Not automatically. Building an app or website using established technologies, frameworks, and design patterns is standard development, not R&D. However, if the project encounters genuine technological uncertainty — for example, achieving real-time performance at unprecedented scale or developing novel algorithms — the work to resolve that uncertainty may qualify.

Can agile development be R&D?

Yes, agile methodology can involve R&D. The BIS Guidelines require a “systematic approach,” and agile sprints with clear hypotheses, iterative testing, and analysis can satisfy this. The key question is whether the sprint work addresses scientific or technological uncertainty, not whether the methodology is agile or waterfall.

Does AI and machine learning qualify?

AI and ML projects frequently qualify because they often involve genuine uncertainty about whether a model can achieve the required accuracy, whether a novel architecture will work, or how to handle edge cases in training data. However, simply using pre-built ML libraries without modification does not typically qualify.

Can I claim for fixing bugs?

Generally no. Routine bug fixing is maintenance, not R&D. However, if a bug reveals a fundamental technological uncertainty — such as a race condition that cannot be solved using known techniques — the work to resolve that underlying uncertainty could qualify.

ソフトウェアとテクノロジーの研究開発

重要な事実

ソフトウェア研究開発は、 コンピュータサイエンスや情報技術の進歩新しい製品を作るだけではありません。
ルーチン開発 確立された枠組み よく知られたパターンは適格ではありません。
前進は アルゴリズム、データ処理、アーキテクチャ、AI/ML、セキュリティ、統合.
両方 製品会社 （SaaS、アプリ）と 社内ITチーム (特注システム) も対象となります。
人件費 開発者、データサイエンティスト、DevOpsエンジニア 通常、対象となる費用の中で最も大きなものとなります。

ソフトウェアの研究開発とは何でしょうか?

ソフトウェアやテクノロジーの研究開発が税務上の研究開発として認められるためには、 コンピュータサイエンスや情報技術の進歩 真の科学的または技術的な不確実性を解決することによって。その進歩は、当該分野の有能な専門家が容易に達成できる範囲を超えるものでなければならない。^[1]

ソフトウェアの研究開発が適格となる一般的な分野は次のとおりです。

新しいアルゴリズム: 既存のアルゴリズムでは効率的に処理できない問題を解決するための新しい計算方法の開発
AIと機械学習: 結果が不確実な新しいモデルアーキテクチャ、トレーニングアプローチ、またはデータ処理パイプラインを作成する
大規模なパフォーマンス: 既知の能力を超える処理速度、スループット、またはレイテンシの目標を達成する
複雑な統合: 実現可能性が不確かな、これまでに実現されていない方法でシステムを接続する
セキュリティと暗号化: サイバーセキュリティや暗号化に対する新たなアプローチを開発し、最先端技術を進歩させる
データエンジニアリング: 既存の技術を超えた斬新な方法でデータを処理、変換、または分析する

不適格なもの

以下の活動はソフトウェア企業では一般的ですが、 しないでください 通常、R&D として認定されます。^[3]

標準開発: 技術的な不確実性なしに、確立されたフレームワーク（React、Django、Rails、.NET）を使用して機能を構築する
構成とカスタマイズ: 市販のソフトウェアまたはCMSプラットフォームのセットアップ
UI/UXデザイン: デザイン作業は科学や技術ではない（ただし、斬新なインターフェースの技術的実装は科学や技術かもしれない）
システム管理: 定期的な展開、監視、メンテナンス
データの入力と移行: 標準ETLツールを使用してシステム間でデータを移動する
テストとQA: 日常的な品質保証（ただし、R&Dの不確実性を解決するためのテストは対象となる場合があります）

重要なテスト: 「私たちが着手する前に、公開されている知識にアクセスできる有能な開発者が、この方法を知っていたか？」と自問してください。答えが「はい」であれば、それは研究開発ではありません。答えが「いいえ」で、解決策を見つけるために体系的なアプローチを用いた場合は、研究開発に該当する可能性が高いです。

適格ソフトウェア研究開発の例

プロジェクト	なぜそれが適格なのか
10ミリ秒未満の遅延で毎秒100万件のトランザクションを処理するリアルタイム不正検出エンジンの開発	既知のパフォーマンス能力を超えている。必要なスループットと精度が同時に達成できるかどうかは不確実である。
複数の管轄区域にわたる非構造化法的文書から構造化データを正確に抽出する自然言語処理 (NLP) システムの作成	新たなAIの課題：既存のNLPモデルでは、ドメイン固有の言語や管轄区域間の差異を十分な精度で処理できない
200 ミリ秒未満の結果整合性で 15 個のマイクロサービスにわたって ACID コンプライアンスを維持する分散データパイプラインを構築する	アーキテクチャの不確実性。既知のパターン（サガ、2相コミット）は、レイテンシと一貫性の要件を同時に満たさない。
製造ラインのスピードで製造部品のサブミリメートルの欠陥を検出する画像認識システムの開発	コンピュータビジョンの課題。利用可能な画像解像度で必要な速度で十分な精度を達成できるかどうかの不確実性。

ソフトウェア企業の典型的な適格費用

ソフトウェアやテクノロジー企業にとって、最も大きなコスト項目は、ほとんどの場合 人件費対象となる役割には通常、次のようなものがあります。^[2]

ソフトウェア開発者およびエンジニア（研究開発時間に応じて配分）
データサイエンティストと機械学習エンジニア
DevOpsおよびインフラストラクチャエンジニア（R＆D関連の課題を解決する場合）
テクニカルアーキテクト（R&Dの設計と計画に費やした時間）
CTOおよび技術リーダー（R&D活動に費やした時間）

その他の一般的なコストには、クラウドコンピューティング (R&D ワークロード用)、専門的なソフトウェアライセンス、外部から提供される労働者 (R&D プロジェクトの契約開発者) などがあります。

ヒント： 多くのソフトウェア企業は、R&Dを「単なる開発」と考え、過小評価しがちです。スプリントのバックログ、Jiraのチケット、技術的負債項目などを確認してみてください。技術的な目標達成方法について真の不確実性を伴う作業はすべて、R&Dの対象になる可能性があります。

ソフトウェア研究開発の文書化

ソフトウェア企業は、既にプロジェクト管理ツールやバージョン管理ツールを活用しているため、研究開発の成果を文書化するのに有利な立場にある場合が多いです。有用な証拠としては、以下のようなものが挙げられます。

Git 履歴: 問題を解決するための反復的な試みを示すコミットメッセージとブランチ
Jira/Trello/Asana: 技術的な課題と調査を説明するチケット
合流点/概念: 技術設計文書とアーキテクチャ決定記録
プルリクエストのレビュー: 技術的なトレードオフと不確実性について議論するコードレビュー
Slack/チーム: チームが技術的な障害について話し合う会話

よくある質問

新しいアプリやウェブサイトの構築は、R&D として認められますか?

必ずしもそうではありません。確立された技術、フレームワーク、デザインパターンを用いてアプリやウェブサイトを構築することは、標準的な開発であり、研究開発ではありません。ただし、プロジェクトが真の技術的不確実性に直面している場合（例えば、前例のない規模でのリアルタイムパフォーマンスの実現や、新しいアルゴリズムの開発など）、その不確実性を解決するための作業は、研究開発として認められる可能性があります。

アジャイル開発は研究開発になり得るか?

はい、アジャイル手法には研究開発を含めることができます。BISガイドラインでは「体系的なアプローチ」が求められており、明確な仮説、反復的なテスト、分析を伴うアジャイルスプリントはこれを満たすことができます。重要なのは、スプリント作業が科学的または技術的な不確実性に対処するかどうかであり、手法がアジャイルかウォーターフォールかということではありません。

AI と機械学習は適格でしょうか?

AIおよびMLプロジェクトは、モデルが必要な精度を達成できるかどうか、新しいアーキテクチャが機能するかどうか、あるいはトレーニングデータにおけるエッジケースをどのように処理するかといった、真の不確実性を伴うことが多いため、多くの場合、適格とみなされます。しかし、既成のMLライブラリをそのまま変更せずに使用するだけでは、通常は適格とみなされません。

バグ修正に対して請求できますか?

一般的にはそうではありません。日常的なバグ修正はメンテナンスであり、研究開発ではありません。ただし、バグによって根本的な技術的不確実性（既知の手法では解決できない競合状態など）が明らかになった場合、その根本的な不確実性を解決するための作業は研究開発に該当する可能性があります。

さらに読む

R&D とは何でしょうか? — BISガイドラインの完全テスト
対象となる研究開発費 — すべての適格コストカテゴリ
R&D技術レポート — 物語の書き方
製造業における研究開発 — 他のセクターの例

シンプルな税務ソフトウェアをお探しですか？

# GoFileはHMRCに認められ、5万社以上の英国企業から信頼されています。数分で設定が完了し、安心して申告できます。

無料で始める

クレジットカード不要・いつでもキャンセル可能