第 3 回：コーディング不要！GUI でデータを投入する「Data Importer」
実体験から学ぶ：非技術者との協働の重要性
あるプロジェクトで、営業チームが持つ顧客データをグラフデータベースに投入する必要がありました。当初は Cypher スクリプトでの一括投入を予定していましたが、Data Importer を使うことで営業チーム自身がデータモデリングに参加できるようになり、より実用的なデータ構造を構築できました。
Data Importer とは何か
Data Importer は Neo4j Workspace に統合されたビジュアルなデータインポートツールです。Cypher コードを書くことなく、マウス操作だけで CSV ファイルからグラフデータを構築できます。
なぜ GUI アプローチが重要なのか
従来のアプローチの課題：
- 技術者のみがデータ投入に関与
- ビジネス要件とデータ構造の乖離
- 反復的な改善が困難
Data Importer による解決：
- ビジネスユーザーの直接参加
- 視覚的なモデリングによる理解促進
- リアルタイムなフィードバックサイクル
Data Importer へのアクセス
基本的なアクセス手順
- Aura コンソールで稼働中のインスタンスを確認
- 「Open」ボタンをクリックして Workspace を起動
- Workspace 内で「Import」タブを選択
実践のコツ： 私は必ずブックマークを以下のように整理しています：
□ Neo4j Auraコンソール（管理用）
□ プロジェクト用Workspace（開発用）
□ Data Importer直リンク（データ担当者用）
実践的なサンプルデータの準備
実際のプロジェクトで使用したデータ構造
私が担当したプロジェクトでは、以下のような企業データを扱いました：
companies.csv
id,name,industry,size,founded_year,headquarters
1,TechCorp Inc,Technology,Large,2010,Tokyo
2,DataSoft Ltd,Software,Medium,2015,Osaka
3,AI Solutions,Artificial Intelligence,Small,2020,Yokohama
employees.csv
id,name,role,email,company_id,start_date
101,John Smith,Developer,john@techcorp.com,1,2021-04-01
102,Jane Doe,Manager,jane@techcorp.com,1,2020-01-15
103,Bob Wilson,Analyst,bob@datasoft.com,2,2022-03-01
projects.csv
id,name,description,company_id,manager_id,budget,start_date
201,AI Chatbot,Customer service automation,1,102,5000000,2023-01-01
202,Data Pipeline,ETL system modernization,2,103,3000000,2023-06-01
CSV ファイル準備のベストプラクティス
私が実践している準備ルール：
1. 文字エンコーディング
推奨: UTF-8（BOM無し）
避ける: Shift_JIS、EUC-JP
確認方法: テキストエディタで文字化けがないかチェック
2. ヘッダー行の設計
良い例: id, company_name, industry_type
悪い例: 会社ID, 会社名, 業界タイプ
理由: 英語カラム名がCypherとの相性が良い
3. ユニーク ID の戦略
企業ID: company_001, company_002...
人物ID: person_001, person_002...
プロジェクトID: project_001, project_002...
実際のトラブル例と対策： あるプロジェクトで日本語のカラム名を使用した結果、後の Cypher クエリが非常に複雑になりました。最初から英語カラム名を使うことを強く推奨します。
ビジュアルなデータモデリング実践
ステップ 1：ファイルの配置とノード定義
実際の操作手順：
-
CSV ファイルをキャンバスにドラッグ&ドロップ
- 複数ファイルの同時アップロード可能
- ファイルサイズ制限：通常 50MB 程度
-
各ファイルにノードラベルを割り当て
companies.csv → :Company
employees.csv → :Employee
projects.csv → :Project -
主キーカラムの指定
- 各ノードタイプで一意となるカラムを選択
- 後のリレーションシップ作成で使用
ステップ 2：プロパティのマッピング
実際のプロジェクトでは、全てのカラムをプロパティにする必要はありません。ビジネス価値に応じて選択します。
私の選択基準：
高優先度（必須プロパティ）
- ビジネス検索で使用
- 集計・分析で必要
- ユニーク制約が必要
中優先度（条件付きプロパティ）
- 表示用途で使用
- フィルタリングで使用
- 将来的な拡張で必要
低優先度（除外検討）
- 内部管理用 ID
- 一時的なフラグ
- 計算で求められる値
ステップ 3：リレーションシップの定義
グラフデータベースの真価は、エンティティ間の関係性にあります。
実際の関係性定義例：
Company → Employee（EMPLOYS）
接続方法: company_id（employees.csv）→ id（companies.csv）
プロパティ: start_date, role, department
方向性: Company → Employee
Employee → Project（MANAGES/WORKS_ON）
接続方法: manager_id → employee.id (MANAGES)
接続方法: 中間テーブルで (WORKS_ON)
プロパティ: role_in_project, allocation_percentage
リレーションシップ設計の実践的なコツ：
-
意味のある名前付け
良い例: EMPLOYS, MANAGES, COLLABORATES_WITH
悪い例: HAS, RELATED_TO, CONNECTS -
方向性の明確化
Company -[EMPLOYS]-> Employee
Employee -[WORKS_ON]-> Project
Employee -[REPORTS_TO]-> Employee -
プロパティの活用
(employee)-[WORKS_ON {role: "Lead Developer", since: "2023-01-01"}]->(project)
インポートの実行と品質確認
プレビュー機能の活用
実際のデータ投入前に、必ずプレビューで確認することが重要です。
プレビューでの確認項目：
データ整合性チェック
□ 欠損した外部キーの検出
□ 重複ノードの確認
□ データ型の不整合
□ 意図しないNULL値
モデル妥当性チェック
□ リレーションシップの方向性
□ ノードラベルの適切性
□ プロパティ名の統一性
□ ビジネスルールとの整合性
実際に発見した問題例：
- 社員 ID の不整合：一部の社員が存在しない会社 ID を参照
- 日付フォーマットの混在：YYYY-MM-DD と MM/DD/YYYY が混在
- 文字コードの問題：特定の文字が文字化け
本格実行とエラーハンドリング
実行時の監視項目：
パフォーマンス指標
処理速度: 1000行/分程度が目安
メモリ使用量: インスタンスサイズに応じて調整
エラー率: 5%以下を維持
エラー対応フロー
1. エラー内容の分析
2. データソースの修正
3. 部分的な再インポート
4. 整合性チェックの実行
私の実際のエラー対応例：
問題: 10,000 行中 500 行でインポートエラー 原因: 日付カラムに不正な値（"N/A"文字列） 解決: CSV の事前クレンジングスクリプト作成
# エラー対応スクリプト例
df['start_date'] = df['start_date'].replace('N/A', None)
df['start_date'] = pd.to_datetime(df['start_date'], errors='coerce')
インポート後の品質確認
データ品質の検証クエリ
インポート完了後は、必ずデータ品質を確認します。
基本的な検証クエリ：
// 1. 全体のデータ量確認
MATCH (n) RETURN labels(n) as NodeType, count(n) as Count
// 2. リレーションシップの確認
MATCH ()-[r]->() RETURN type(r) as RelType, count(r) as Count
// 3. 孤立ノード（関係性のないノード）の検出
MATCH (n) WHERE NOT (n)--() RETURN labels(n), count(n)
// 4. 重複の可能性があるノードの確認
MATCH (n:Company)
WITH n.name as name, collect(n) as nodes
WHERE size(nodes) > 1
RETURN name, size(nodes)
ビジネスルールの検証
技術的な整合性だけでなく、ビジネスルールも確認します。
実際の検証例：
// 管理者が複数プロジェクトを管理しているかチェック
MATCH (emp:Employee)-[MANAGES]->(proj:Project)
WITH emp, count(proj) as project_count
WHERE project_count > 5
RETURN emp.name, project_count
ORDER BY project_count DESC
// 会社の設立年と社員の入社日の整合性チェック
MATCH (comp:Company)<-[EMPLOYS]-(emp:Employee)
WHERE comp.founded_year > year(date(emp.start_date))
RETURN comp.name, comp.founded_year, emp.name, emp.start_date
トラブルシューティングとベストプラクティス
よくある問題と解決策
実際のプロジェクトで遭遇した問題をまとめました。
問題 1：大量データでのタイムアウト
症状: 100 万行超の CSV でインポートが失敗 解決策:
- ファイルの分割（10-50 万行単位）
- バッチ処理での段階的インポート
- インスタンスサイズの一時的な増強
問題 2：文字化けの発生
症状: 日本語データが文字化け 解決策:
- UTF-8（BOM 無し）での保存確認
- CSV エディタでの事前確認
- テストデータでの事前検証
問題 3：リレーションシップが作成されない
症状: ノードは作成されるが関係性が空 解決策:
- 外部キーの存在確認
- データ型の一致確認
- NULL 値の処理方針決定
運用における改善提案
継続的な改善サイクル:
- データ投入: 標準化されたプロセス
- 品質検証: 自動化されたチェック
- 問題分析: 根本原因の特定
- プロセス改善: 再発防止策の実装
次のステップ：データの活用開始
Data Importer でデータ投入が完了したら、次は実際にデータを操作・分析する段階に入ります。
第 4 回では以下を扱います：
- Neo4j Workspace での基本的なクエリ実行
- データ可視化の各種オプション
- グラフビューでのインタラクティブ操作
実践のまとめ：
- ビジネスユーザーとの協働によるモデリング
- 段階的なデータ品質確認
- プレビュー機能の活用による事前検証
- 継続的な改善プロセスの確立
次回: 第 4 回：グラフの世界へ！「Neo4j Workspace」でのデータ可視化と基本操作
著者: hnish - walk-with-ai AI/DX コンサルタント
最終更新: 2025 年 7 月 1 日