最終更新：2026年9月7日。ATLAS.ti 26 Mac版の公式マニュアルは26.1.1で、Project CloudはBetaとして扱われています。公式マニュアルで確認できる範囲では、同じプロジェクトを2台で同時編集する用途には対応していません。したがって、ATLAS.ti 26 Project Cloudは個人の端末間継続と非同期共有には適しますが、複数人の同時編集用には採用しない、という判断が安全です。
この記事を読む対象
質的研究の責任者は、主プロジェクト、権限、配布、回収のルールを決める必要があります。
大学院生やコーダーは、MacとWindowsの間で最新版を取り違えない運用が必要です。
大学の技術担当者は、遠隔Mac、ライセンス、保管場所、デスクトップ版の導入範囲を確認します。
[ SECTION_01 ] 4つの経路を先に分ける
Project Cloudだけで課題を解決しようとすると、端末間の継続、チーム分担、リアルタイム編集、コーダー一致度検証が混同されます。最初に、目的と採用経路を切り分けてください。
| 研究上の目的 | 優先する経路 | 合格条件 | 停止条件 |
|---|---|---|---|
| MacとWindowsで1人が継続する | Project Cloud | 最新版を取得し、1台ずつ編集・送信する | 2台に未送信変更が残る |
| メンバーが時間をずらして分担する | 主プロジェクト＋独立した副本 | 文書、コード、作業者名、回収方法を統一する | 副本を自動統合できると誤認する |
| 複数人が同時に作業する | ATLAS.ti Webを候補にする | Web側の機能と成果物をサンプルで確認する | デスクトップ版との直接互換を前提にする |
| デスクトップ分析と一致度検証を行う | 配布・コーディング・プロジェクト統合 | ユーザー情報、ID、競合、重複文書を確認する | 各自が別の体系を作っている |
ATLAS.ti Webを選ぶ場合も、デスクトップ版と同じプロジェクトが自動的に見えるとは扱いません。公式のProject Cloudの説明では、デスクトップ版のProject CloudプロジェクトとATLAS.ti Webプロジェクトの相互可視性に制限があります。
[ SECTION_02 ] シナリオ1：個人がMacとWindowsを行き来する
この用途では、Project Cloudが比較的判断しやすい選択肢です。ただし、クラウド上に1つの共同編集画面があるのではなく、端末側にプロジェクトの副本が保存され、作業後に状態を同期する仕組みとして理解します。
開始前には、前回の作業者がアップロードを完了しているか確認します。最新版を取得したら、その端末だけで編集し、終了時にアップロードします。別の端末を開いたまま同時にコードを追加する運用は避けてください。
注意：2台に未送信の変更があると分かった時点で、コーディングを続けないでください。まず最後に共有された版を基準にし、どの変更を残すかを記録してから再開します。
最小検証は、脱個人情報化した短い文書を1つ用意し、Macでコードを追加して送信し、Windowsで最新版を取得して確認する流れです。逆方向も実施します。文書、コード、コメント、書き出し結果が一致すれば、個人の端末間継続については合格です。
[ SECTION_03 ] シナリオ2：小規模チームの非同期分担
非同期分担では、メンバーが同じプロジェクトを同時に開くのではなく、主プロジェクトから独立した作業用副本を受け取ります。ATLAS.tiのチーム作業に関する公式手順に沿って、主担当、配布日、回収先、採用する版を先に決めます。
最低限、次の項目を台帳化します。
- 主プロジェクトの保管者と読み取り専用の原本
- メンバー名と担当文書
- 副本のファイル名、作業期間、返却日時
- 使用したコード体系と変更を認める範囲
- 回収後の検証担当者
- 統合前に残すバックアップ
受け入れテストは、脱個人情報化したインタビュー資料を1回分だけ使います。責任者が副本を配り、メンバーが別々にコーディングし、回収後に結果を確認します。副本が複数あること自体は失敗ではありません。失敗なのは、副本の差分が自動的に1つへ統合されると考えることです。
[ SECTION_04 ] シナリオ3：リアルタイムで同時にコーディングする
複数人が同じ文書を同時に読み、同時にコードを付ける必要がある場合、Project Cloudは候補から外します。公式説明が示す同時編集の制限と、ATLAS.ti Webとのプロジェクト可視性の制限を、導入判断の前提にしてください。
ATLAS.ti Webを使う場合は、次の順で確認します。
- 研究グループのアカウントでサンプルプロジェクトを作成します。
- 2人以上のメンバーを招待し、同じ文書への編集権限を確認します。
- コード、コメント、メモ、文書属性を別のメンバーから確認します。
- Web側で書き出した成果物を保管します。
- デスクトップ版で必要な分析がある場合、移行後に何が保持されるかを確認します。
ATLAS.ti Webで作業できることと、デスクトップ版の分析機能を同じ状態で使えることは別です。研究手順が高度なデスクトップ分析、複雑な統合、特定形式の書き出しに依存する場合、リアルタイム編集と最終分析を段階的に分けます。
[ SECTION_05 ] シナリオ4：コーダー一致度と正式なプロジェクト統合
一致度検証では、全員が共通の主プロジェクトから同じ文書とコード体系を受け取る必要があります。各自が新しい文書を作り、似た名前のコードを別々に登録すると、統合後に比較対象が不明確になります。
コーダー一致度の公式説明とMac版の統合手順を確認し、次の4点を記録します。
- コーディングを行ったユーザーの識別情報
- 文書やコードに付与されたエンティティID
- 統合時に生じた競合
- 重複文書の有無
正式な統合では、先に主プロジェクトを読み取り専用で保存します。次に、1人分の副本だけで試しに統合します。文書が重複せず、コーダー名が残り、比較に必要なコードと割り当てが確認できたら、残りの副本へ進みます。
プロジェクト統合の公式手順でも、統合前の構造とユーザー情報の確認が重要です。統合後に問題が見つかっても、原本と各副本が保存されていれば戻せます。
[ SECTION_06 ] シナリオ5：インタビュー資料と大容量メディア
インタビュー音声や動画をProject Cloudへ置く前に、倫理審査、学内のデータ分類、契約上の保管場所、国外保管の扱いを確認します。ここでは法的な可否を断定せず、研究機関の規程と承認記録を優先してください。
データには、プロジェクト内部へ取り込むファイルと、外部リンクで参照するメディアがあります。外部リンク方式では、別の端末や別のアカウントから同じ場所へ到達できるかを確認します。リンク切れだけでなく、読み取り権限、保存期間、認証状態も記録します。
次の状態ならクラウド経路を止めます。
- 学内規程上、対象資料をクラウドへ保存できない
- 倫理審査の保管条件とサービスの保管場所が一致しない
- 端末を替えると音声や動画のリンクが再現できない
- 大容量ファイルの取得失敗が繰り返される
その場合は、原資料を読み取り専用で保管し、脱個人情報化した作業用資料だけを別経路で扱います。クラウドへ置いたから安全、あるいはローカルだから安全、と単純化しないことが重要です。
[ SECTION_07 ] 第一歩：受け入れチェックを1回で終える
以下は、課題責任者と技術担当者が共同で実行できるチェックリストです。
- [ ] ATLAS.ti 26 Mac版の公式マニュアルとProject CloudのBeta表示を確認する
- [ ] 主プロジェクトの保管者、読み取り専用原本、バックアップ先を決める
- [ ] Mac、Windows、Webのどの経路を誰が使うか台帳に記録する
- [ ] 同じプロジェクトを2台で同時編集しない規則を文書化する
- [ ] 脱個人情報化した文書で取得、編集、送信、再取得を試す
- [ ] メンバー副本のファイル名、担当、回収日時を統一する
- [ ] ユーザー情報、エンティティID、重複文書、競合レポートを確認する
- [ ] ATLAS.ti Webからデスクトップ版へ直接続けられると仮定せず、移行サンプルを試す
- [ ] 音声・動画の内部ファイルと外部リンクを別々に確認する
- [ ] 書き出し成果物をLinuxまたはWindows側で開き、研究工程へ戻せるか確認する
- [ ] 失敗時に戻す版、停止する担当者、再開条件を決める
ATLAS.ti 26のシステム要件も、大学の端末や遠隔Macを選ぶ前に確認します。ライセンス認証については、公式のライセンス案内に沿って、研究グループのアカウント運用と端末の交換条件を確認してください。
[ SECTION_08 ] 遠隔Macを使う場合の採用条件
研究室にMacがなく、デスクトップ版の実作業だけを確認したい場合は、正式な受訪者データをいきなり移さないことが原則です。まず脱個人情報化したプロジェクトで、アプリの起動、ライセンス認証、Project Cloudからの取得、コード付与、分析、書き出し、終了時の清掃を順に確認します。
遠隔操作が可能でも、次のどれかに該当すれば採用を保留します。
- 研究グループのライセンス条件を確認できない
- 作業終了後にプロジェクトや認証情報を消去できない
- 成果物を既存のWindowsまたはLinux環境へ戻せない
- 音声・動画の参照経路が安定しない
- 管理者権限や保管場所を担当者が説明できない
NOVAKVMのMac環境の案内を確認する場合も、サービスの紹介だけで判断せず、上記のサンプル検証を先に行います。購入とレンタルを比較する段階では、Macを購入する場合の検討材料も参照し、短期の受け入れ確認と長期運用を分けて考えてください。
[ SECTION_09 ] 4経路の最終判定
Project Cloudは、個人の端末間継続や、時間をずらした副本の受け渡しに向いています。リアルタイムの共同編集、デスクトップ版での正式な統合、機密性の高い大容量資料は、それぞれ別の確認が必要です。
研究室の既存環境がWindowsやLinux中心の場合、ローカルMacの購入は初期費用だけでなく、保守、端末管理、利用者交代時のアカウント整理も発生します。一方、遠隔Macは通信品質、ライセンス、データ持ち出し、終了時の清掃を自分たちで確認しなければなりません。
そのため、長期にわたり毎日大量の資料を処理する研究室や、物理ポート・ローカル保存が必須の運用では購入や学内設備が適する場合があります。反対に、ATLAS.ti Mac版の受け入れ確認、短期の解析、既存のWindows環境では再現できない工程だけが目的なら、NOVAKVMの周期契約による遠隔Macでサンプル検証を先に行う方が、不要な端末購入を避けやすい選択です。
[ SECTION_10 ] よくある確認
ATLAS.ti Project Cloudで同時編集できるか
できません。Project Cloudは、2台で同じプロジェクトを同時に編集する共同作業空間として扱わないでください。最新版を取得した1台だけで編集し、アップロード完了後に次の作業者へ渡します。
Mac版とWindows版を協働させる方法
1人の継続利用なら、最新版の取得と作業後のアップロードを徹底します。複数人なら、主プロジェクトから副本を配り、担当者名と回収時刻を記録します。
ATLAS.ti Webとデスクトップ版の関係
両者のプロジェクトが自動的に同じ場所へ表示されるとは限りません。Webでの共同作業とデスクトップ版の高度な分析を、別工程としてサンプル検証してください。
複数人のコーディングを統合する方法
共通の文書とコード体系から副本を作り、統合時にユーザー情報、エンティティID、重複文書、競合を確認します。統合前の原本は変更しません。
Macがない研究室での確認方法
個人情報を含まないサンプルを遠隔Macへ置き、取得、分析、書き出し、終了時の清掃まで確認します。正式データの移行は、成果物と保管条件を確認してから行います。
ATLAS.ti 26 Project Cloudの研究グループ協働は、「何人でも同時に編集できるか」ではなく、「どの場面で、どの版を主とし、どの成果物を戻すか」で判断します。最初に脱個人情報化した1回分のプロジェクトを使い、Project Cloud、ATLAS.ti Web、デスクトップ統合、遠隔Macの4経路を順に受け入れ確認するのが安全です。