DjangoでSQLiteへ接続するには、使用中のsettings.pyのDATABASESにENGINEとNAMEを指定します。アプリから使うPythonのsqlite3モジュールと、dbshellが起動するsqlite3実行ファイルは別物です。このページはDjango配下の接続手順として説明し、Java/Node.jsの一般的なSQLite入門とは分けます。

以前のWindowsダウンロード画面

復元した元画像です。赤枠は2017年当時のsqlite-tools（コマンド群）で、その上のDLL配布とは用途が異なります。3.20.1/x86という古いファイル名を現在の推奨版とは扱いません。現在のOS/CPU向け配布物はSQLite公式ダウンロードで確認してください。PythonやOS自体が対応済みであることも別に確認します。

まず「何につながるか」を確認する

確認する層	役割	失敗したときの切り分け
DATABASESのdefault	使用バックエンドとDBファイルを選ぶ	起動設定・環境・alias・実ファイルを照合する
Pythonのsqlite3	DjangoのSQLiteバックエンドが利用するライブラリ	使用中のPythonでimport/SQLiteライブラリ版を確認する
sqlite3コマンド	dbshellが外部プロセスとして起動するCLI	同じ実行ユーザーのPATHとコマンドの版を確認する

管理下の開発用プロジェクトで、manage.pyのある場所と使うvirtualenv、DJANGO_SETTINGS_MODULE/--settingsを照合します。以下は新しい教材プロジェクト向けの設定断片です。既存DATABASES全体や別のaliasを上書きしたり、稼働中のDBをこのパスへ切り替えたりしません。既存のBASE_DIRがPathならその定義を使い、文字列ならPathへ変換するなど型を合わせます。

from pathlib import Path

# Fragment for a new learning project, not a replacement for existing settings.
BASE_DIR = Path(__file__).resolve().parent.parent
DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": BASE_DIR / "db.sqlite3",
    }
}

SQLiteのNAMEはファイルの場所です。上例ではsettings.pyの位置から基準ディレクトリを作るため、起動時のカレントディレクトリだけで別DBを選ぶことを避けられます。相対パスや誤字で存在しない名前へ接続すると、別の空DBが作られることがあります。接続成功やSELECT 1の成功だけでは、意図したファイル・必要なテーブル・migration適用済みを証明しません。

既存ファイルを新規作成せずに調べる

既存DBの確認では、対象の実ファイルを先に確かめます。次は管理者のローカル利用に限った補助関数です。パスが存在しなければ失敗させ、SQLiteのURI mode=roで開くため、名前間違いを空ファイルの新規作成で見逃しません。返すのはライブラリ版と最大20個のテーブル名だけで、テーブル中身は出しません。それでも構造情報なので公開ページやログへ出さず、Web入力のパスを渡さないでください。

from contextlib import closing
from pathlib import Path
import sqlite3


def inspect_existing(path):
    """Administrative local use only; never accept a path from a web request."""
    database = Path(path).resolve(strict=True)
    if not database.is_file():
        raise ValueError("Expected an existing regular SQLite file")
    with closing(sqlite3.connect(database.as_uri() + "?mode=ro", uri=True)) as conn:
        version = conn.execute("SELECT sqlite_version()").fetchone()[0]
        tables = conn.execute(
            "SELECT name FROM sqlite_schema WHERE type = ? ORDER BY name LIMIT 20",
            ("table",),
        ).fetchall()
        return {"sqlite_version": version, "tables": [row[0] for row in tables]}


def inspect_default_sqlite():
    from django.db import connections

    config = connections["default"].settings_dict
    if config["ENGINE"] != "django.db.backends.sqlite3":
        raise ValueError("Default database is not SQLite")
    name = str(config["NAME"])
    if not name or name == ":memory:" or name.startswith("file:"):
        raise ValueError("This example supports an existing ordinary file only")
    return inspect_existing(name)

inspect_existing(管理下の既存ファイルのパス)で使用します。Djangoの設定が読み込まれた管理用shellからinspect_default_sqlite()を呼ぶ場合も、通常のファイルNAMEだけが対象です。これはDjangoの実接続ではなく別の読取専用接続です。URI/メモリDB・独自バックエンド・OPTIONSの再現・暗号化・稼働プロセスの接続先/整合性/業務認可の保証には使えません。ファイル存在検査とopenは一つの原子的操作でもありません。

dbshellでCLIへ入る

元のコマンドは後述の旧コード表に保持しています。使用するDB aliasを明示する場合は、開発用プロジェクトでpython manage.py dbshell --database=defaultとします。DjangoはPATH上のsqlite3コマンドを起動します。--databaseはファイル名ではなくDATABASESのキーです。通常のdbshellは読取専用を保証せず、起動設定自体が実行する処理もあるため、知らない本番プロジェクトを試験に使いません。

python -c "import sqlite3; print(sqlite3.sqlite_version)"
sqlite3 --version
python manage.py dbshell --database=default

# sqlite3のプロンプトへ入った後（確認用、行データは出さない）
.databases
.tables
.quit

最初の版はPythonが使うSQLiteライブラリ、2つ目はCLIの版なので、一致は必須ではありません。.databasesにはファイルパスが出ます。プロンプトのsqlite>や説明用の#行は入力しません。SQLiteのドットコマンドにはSQL末尾のセミコロンを付けず、SELECT等のSQLには付けます。

エラーごとに対応を分ける

• 「sqlite3 program installed or on your path」：CLIが見つからない場合のエラーです。Pythonのimport成功をCLI導入済みの証拠にしません。Windowsならwhere.exe sqlite3、POSIX shellならcommand -v sqlite3で、同じユーザー/環境の探索先を確認します。必要な場合に公式配布を用い、PATHを丸ごと上書きしません。
• 「unable to open database file」：NAMEの誤り、親ディレクトリ、実行ユーザーの権限、読取専用配置などを確認します。権限を一律777へ広げたりDBファイルを削除したりしません。書込にはファイルだけでなくjournal等を置くディレクトリの条件も関係します。
• 「no such table」：別DB/別alias・テーブル名・適用済み変更を調べます。診断としてmigrationやテーブル作成を実行しません。新規DBの初期構築と既存DBの障害対応を分離します。
• 「database is locked」：競合する処理とトランザクションの長さを調べます。timeout延長やWALを即時の万能修正とせず、強制解除・journal/WALファイル削除・稼働DBのコピーをしません。

Pythonのwithは接続を閉じない

PythonのConnectionをwithに渡すと、対象のトランザクションを正常終了時にcommit、例外時にrollbackしますが、接続のcloseではありません。処理の有無はautocommit等にも依存します。次はPython3.12以降の独立したメモリDB教材で、autocommit=Falseとcontextlib.closingを明示しています。Djangoが管理する接続へこのsqlite3用の管理方法をそのまま混ぜません。

from contextlib import closing
import sqlite3


def memory_example():
    # Explicit transaction behavior, independent of future default changes.
    with closing(sqlite3.connect(":memory:", autocommit=False)) as conn:
        conn.execute("CREATE TABLE notes (message TEXT NOT NULL)")
        conn.commit()
        with conn:
            conn.execute("INSERT INTO notes (message) VALUES (?)", ("example",))
        return conn.execute("SELECT message FROM notes").fetchall()

with connを抜けた後も、その接続は使用できます。一方、closingを抜けた後は使用できません。メモリDBは通常それぞれの接続に独立しており、別接続から同じデータが見える前提にもできません。

元のDjango接続手順とコード表

以下は元記事の設定表・dbshell・エラー・旧起動メッセージを保持した保守資料です。os.path.join方式はosのimportと正しいBASE_DIRが前提です。SQLite3.20.1の起動表示は過去の出力で、現在の導入目標ではありません。CLIが開いたことと意図したDBを確認できたことを分けてください。

djangoの設定ファイルであるsettings.pyのDATABASESでデータベースの接続設定ができます。

settings.py
DATABASES = {     'default': {         'ENGINE': 'django.db.backends.sqlite3',         'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),     } }

ENGINEではデータベースの種類を選択します。

SQLite：'django.db.backends.sqlite3'

 

NAMEではデータベースの名前を設定します。

os.path.join(ディレクトリ名, ファイル名)

os.path.join(BASE_DIR, 'db.sqlite3'),

 

プロジェクトのルートディレクトリに移動します。

　※ルートディレクトリ：「manage.py」のあるディレクトリ

 

次は元のdbshellコマンドです。使用環境/PATH/設定を確認済みの開発用プロジェクトでCLIを起動する例であり、正しいDBやテーブルの存在の証明ではありません。

python manage.py dbshell

 

【接続エラーが発生した場合】

以下のエラーメッセージが出力された場合。

CommandError: You appear not to have the 'sqlite3' program installed or on your path.

確認点：同じユーザーのPATHからsqlite3 CLIを見つけられるか調べます。未導入だけでなく探索先の違いも候補です。Pythonのsqlite3モジュールの有無とは別です。

１．公式のダウンロードサイトにアクセスしましょう。公式サイトはこちら。

２．「command-line shell program」をダウンロードします。

　　OSによってダウンロードするファイルを選択しましょう。

　　以下の例はOSがWindowsの場合です。

     （旧ダウンロード画像は序盤に掲載）

３．解凍したフォルダを任意の場所に設置し、環境変数のPathに登録しましょう。

　　環境変数の設定方法はこちらを参照してください。

４．コマンドプロンプトを再起動してプロジェクトのルートディレクトリに移動、DBへの接続コマンドを実行しましょう。

５．次は旧CLIの起動表示です。版番号は過去の記録で、正しいDBファイルへ接続できた証明ではありません。.databases等の確認と分けます。

SQLite version 3.20.1 2017-08-24 16:21:36 Enter ".help" for usage hints.

 

検証範囲と関連記事

2026年10月26日確認。掲載した設定断片・読取専用関数・メモリDB例をPython3.12.10/Django5.2.18/SQLite3.49.1で隔離実行し、誤パスの新規作成防止、読取専用書込拒否、commit/rollbackとcloseの違いを検査しました。dbshellの引数組立とCLI不足の例外は外部起動を置換して確認し、実CLI/Windows導入GUI・稼働プロセス・本番DB・並列負荷は検証していません。CWiki自身のMySQL接続設定を変える記事ではありません。

データベースへの接続と操作の一覧から他の子ページを選べます。設定の概要はDjangoの親ページも参照してください。

公式資料：DjangoのDATABASES、dbshellとCLIの要件、SQLiteバックエンドの注意、SQLite CLI、PythonのConnection context manager。